abs(Decimal(8.95)) > 8.95 = True ? Comparing Decimal with float is.. not throwing an error?

[Magnie]

Bug report

Bug description:

I ran into a weird issue where abs(Decimal(8.95)) > 8.95 is returning True:

Python 3.10.12 (main, Feb  4 2025, 14:57:36) [GCC 11.4.0] on linux
>>> from decimal import Decimal
>>> Decimal(1.0) > 1.0
False
>>> abs(Decimal(1.0)) > 1.0
False
>>> Decimal(8.95) > 8.95
False
>>> abs(Decimal(8.95)) > 8.95
True
>>> type(abs(Decimal(8.95)))
<class 'decimal.Decimal'>
>>> Decimal(8.95)
Decimal('8.949999999999999289457264239899814128875732421875')
>>> abs(Decimal(8.95))
Decimal('8.949999999999999289457264240')

I would normally expect to get an error like this:

>>> Decimal(1.0) + 1.0
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'decimal.Decimal' and 'float'

CPython versions tested on:

3.10

Operating systems tested on:

Linux

[picnixz]

Is the issue still present on 3.12/3.13 or 3.14? 3.10 won't get any updates as it's security-only.

cc @skirpichev I'm a bit surprised that abs(D(X)) does something when D(X) > 0 but maybe it's some specs I forgot

[zware]

I believe this is expected; see the documentation, particularly around signals, traps, and FloatOperation which is disabled by default. Note also that Inexact plays a role here; the default precision of 28 is smaller than the precision of Decimal(8.95) (somewhere around 50), so abs() winds up throwing away several trailing digits.

[picnixz]

Actually, the docs for abs() seem to hint that we need to look at those for Decimal.copy_abs, which say:

Return the absolute value of the argument. This operation is unaffected by the context and is quiet: no flags are changed and no rounding is performed.

I guess it's because of the context that is being ignored. However Inexact should be used when we're having rounding, but in this case, the docs seem to say that it's not the case. So I'm not really sure whether it's expected or not (or maybe misdocumented)

[Magnie]

@picnixz

Python 3.12.8 (main, Dec 12 2024, 09:41:14) [GCC 8.5.0 20210514 (Red Hat 8.5.0-22)] on linux
>>> abs(Decimal(8.95)) > 8.95
True

These two use Docker:

# docker run -it python:latest
Python 3.13.2 (main, Feb 25 2025, 05:25:21) [GCC 12.2.0] on linux
>>> abs(Decimal(8.95)) > 8.95
True

# docker run -it python:3.14.0a5-bookworm
Python 3.14.0a5 (main, Feb 25 2025, 05:23:09) [GCC 12.2.0] on linux
>>> abs(Decimal(8.95)) > 8.95
True

@zware Yeah, I discovered the traps soon after I posted this. I plan to use it to find these weird cases, but I believe abs(Decimal(8.95)) > 8.95 == True is still a bug because the value is still technically less than 8.95 according to Decimal:

>>> Decimal(8.95)
Decimal('8.949999999999999289457264239899814128875732421875')
>>> abs(Decimal(8.95))
Decimal('8.949999999999999289457264240')

[picnixz]

Huh ok nevermind: the docstring actually say:

    def __abs__(self, round=True, context=None):
        """Returns the absolute value of self.

        If the keyword argument 'round' is false, do not round.  The
        expression self.__abs__(round=False) is equivalent to
        self.copy_abs().
        """

I think we should mention what happens when invoking the abs built-in (at least in the Python implementation) because it's not really explained. I think the C implementation does the same (probably) but I'll need to check.

[skirpichev]

Is the issue still present on 3.12/3.13 or 3.14?

Sure.

I'm a bit surprised that abs(D(X)) does something when D(X) > 0

Normalization. @zware correct, 8.95 can't be converted exactly to a decimal with default precision.

>>> abs(Decimal(8.95)) == Decimal(8.95)
False
>>> abs(Decimal(8.95)) == Decimal(8.95).normalize()
True
>>> decimal.getcontext().prec=100
>>> abs(Decimal(8.95)) > 8.95  # just as expected
False

Docs says (FloatOperation): "If the signal is not trapped (default), mixing floats and Decimals is permitted in the Decimal constructor, create_decimal() and all comparison operators. Both conversion and comparisons are exact."

So, I don't think it's a bug.

[picnixz]

Should we perhaps explicitly document __abs__ though? because there is mention of copy_abs but I can't find docs about the (non-standard) behaviour of __abs__.