[ python-Bugs-1031480 ] decimal module inconsistent with integers and floats

[SourceForge.net]

Bugs item #1031480, was opened at 2004-09-20 14:52
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1031480&group_id=5470

Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Anthony Tuininga (atuining)
Assigned to: Tim Peters (tim_one)
Summary: decimal module inconsistent with integers and floats

Initial Comment:
The Decimal class behaves differently from the builtin
integer and float classes when performing modulus and
integer division operations:

>>> decimal.Decimal("14") % decimal.Decimal("10)
Decimal("4")
>>> decimal.Decimal("-14") % decimal.Decimal("10")
Decimal("-4)
>>> 14 % 10
4
>>> -14 % 10
6

Similar behavior occurs with negative numbers with the
integer division operator //.

Should these behave the same way?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-09-21 20:26

Message:
Logged In: YES 
user_id=31435

Alas, there's no good solution to this.  Python's definition of 
mod doesn't make sense for floats.  Consider, e.g.,

    (-1e-100) % 1e100

math.fmod() applied to this returns (the exactly correct) -1e-
100, but Python's float.__mod__ returns the absurd (on more 
than one count) 1e100.  math.fmod() can always compute an 
exactly correct result, but float.__mod__ cannot.  As the 
example shows, float.__mod__(x, y) can't even guarantee abs
(x % y) < abs(y) for non-zero y (but math.fmod() can).

OTOH, math.fmod's "sign of the first argument" rule is silly 
compared to Python's "sign of the second argument" rule for 
integers.

It's a mistake to believe that one definition of mod "should" 
work across numeric types.  Since Decimal is in fact a floating 
type, I'd prefer to stick to the IBM spec's definition, which 
(unlike Python's) makes sense for floats.

That's not a good solution; but neither would be extending 
the IBM spec to introduce a broken-for-floats meaning just 
because Python's float.__mod__ is broken.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-09-20 23:55

Message:
Logged In: YES 
user_id=80475

Tim, what do you think?  Should the python operators behave
the same across numeric types while leaving the direct spec
API intact or would it be too suprising to have the
operators functioning in a way not contemplated by the spec.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1031480&group_id=5470