[issue2531] float compared to decimal is silently incorrect.

Mark Dickinson added the comment: Merged to py3k in r79668. -- resolution: -> fixed status: open -> closed ___ Python tracker ___ ___

[issue2531] float compared to decimal is silently incorrect.

Mark Dickinson added the comment: Float-to-decimal comparisons have been fixed, and the Decimal hash function changed so that numerically equal Decimal and float instances hash equal, in r79583. The idea of raising an exception for float<->Decimal comparisons was discarded partly for backwar

[issue2531] float compared to decimal is silently incorrect.

Mark Dickinson added the comment: For anyone interested, there's an ongoing python-dev discussion about how to resolve this at http://mail.python.org/pipermail/python-dev/2010-March/098437.html -- ___ Python tracker

[issue2531] float compared to decimal is silently incorrect.

Mark Dickinson added the comment: Here's a patch: - comparisons between a Decimal and float produce a result based on the numeric values of the Decimal and float - change Decimal.__hash__ so that floats and Decimals with (exactly) equal value have the same hash. This preserves the

[issue2531] float compared to decimal is silently incorrect.

Changes by Vasily Ivanov : -- nosy: +bas ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/

[issue2531] float compared to decimal is silently incorrect.

Mark Dickinson added the comment: Stefan: the problem is backwards compatibility. In 2.6 it's possible to sort a heterogeneous list that contains both Decimal instances and floats. The resulting order may not be particularly meaningful, but for some applications that doesn't matter. If we

[issue2531] float compared to decimal is silently incorrect.

Stefan Krah added the comment: I'm new to this thread, so I hope I didn't miss anything that has been said already. I don't fully understand why TypeError cannot be raised in 2.x. The 2.6 documentation for tp_richcompare says: "If you want to implement a type for which only a limited set of com

[issue2531] float compared to decimal is silently incorrect.

Mark Dickinson added the comment: So here's the plan for trunk. The big question is: what should be done for py3k? For trunk: - all comparisons (==, !=, <=, >=, <, >) between floats and Decimals return the correct numerical result, as though the float were converted to a Decimal with

[issue2531] float compared to decimal is silently incorrect.

Mark Dickinson added the comment: I'll try to find time to look at this again before 2.7 beta. -- assignee: -> mark.dickinson ___ Python tracker ___

[issue2531] float compared to decimal is silently incorrect.

Changes by Stefan Krah : -- nosy: +skrah ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/

[issue2531] float compared to decimal is silently incorrect.

Changes by Florent Xicluna : -- versions: +Python 2.7 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue2531] float compared to decimal is silently incorrect.

Bert Hughes added the comment: Expressions like "Decimal('100.0') < .01" being silently wrong (True!) is *very* dangerous behavior, it should raise exception like any other Decimal-float operation, and hopefully will be back-ported to 2.7. Eg: 3rd party module kinterbasdb, which provides acc

[issue2531] float compared to decimal is silently incorrect.

Changes by Mark Dickinson : -- nosy: +adamtj ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue2531] float compared to decimal is silently incorrect.

Mark Dickinson added the comment: Just closed issue 7323 as a duplicate of this one. I think this issue is worth reopening: with the backport of the py3k correctly rounded string <-> float conversions, there might now be a reasonable way to rewrite Decimal.__hash__ so that it's consistent wi

[issue2531] float compared to decimal is silently incorrect.

Jeremy Dunck added the comment: I'm interested. I just had already said my peace and didn't know my prior interest wasn't being counted. The patch uploaded by dmmartins seemed good to me. I'm probably biased, since this bug affected me. -- ___ Pyt

[issue2531] float compared to decimal is silently incorrect.

Raymond Hettinger added the comment: Closing since no one seems interested. -- resolution: -> wont fix status: open -> closed ___ Python tracker ___

[issue2531] float compared to decimal is silently incorrect.

Changes by Mark Dickinson : -- assignee: marketdickinson -> ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: htt

[issue2531] float compared to decimal is silently incorrect.

Mark Dickinson added the comment: Unassigning myself. Does anyone beside Raymond and me have strong opinions about how/whether this problem should be fixed? -- ___ Python tracker _

[issue2531] float compared to decimal is silently incorrect.

Mark Dickinson added the comment: The downside is the potential confusion arising from using one method (comparison of actual numerical value) for <, <=, >, >=, and a different method (decimals and floats are never equal) for == and !=. -- ___ Python

[issue2531] float compared to decimal is silently incorrect.

Raymond Hettinger added the comment: I'm not seeing the downside. This gives better answers than it does now but doesn't commit us to anything else. -- ___ Python tracker ___ __

[issue2531] float compared to decimal is silently incorrect.

Mark Dickinson added the comment: On Fri, Apr 17, 2009 at 3:45 AM, Raymond Hettinger wrote: > Mark, any thoughts?  I would like to apply this patch for ordering > comparisons other than __eq__ and __ne__. Hi Raymond, Sorry for not responding to this sooner. I'll post something to the issue tr

[issue2531] float compared to decimal is silently incorrect.

Raymond Hettinger added the comment: Mark, any thoughts? I would like to apply this patch for ordering comparisons other than __eq__ and __ne__. -- ___ Python tracker ___ __

[issue2531] float compared to decimal is silently incorrect.

Changes by Raymond Hettinger : -- assignee: rhettinger -> marketdickinson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsu

[issue2531] float compared to decimal is silently incorrect.

Raymond Hettinger added the comment: Mark, I looked at your patch again and think we should support relaxed conversions for ordering comparisons but not equality/inequality. This will improve on the current situation where we get flat-out misleading results for <, <=, >, and >=. It keeps the s

[issue2531] float compared to decimal is silently incorrect.

Mark Dickinson added the comment: Removing easy keyword, since I don't think it applies here. The problem here is hashing: either we break the rule that if two objects compare equal then they hash equal, or we fix hash so that e.g., hash(Decimal('2.5')) == hash(2.5). For the latter, the least

[issue2531] float compared to decimal is silently incorrect.

Raymond Hettinger added the comment: I'll look at this more later today. -- ___ Python tracker ___ ___ Python-bugs-list mailing list U

[issue2531] float compared to decimal is silently incorrect.

Mark Dickinson added the comment: One more consideration: if Decimal('2.5') == 2.5 is True, should we also be fixing the Decimal hash method so that hash(Decimal('2.5')) == hash(2.5)? -- ___ Python tracker _

[issue2531] float compared to decimal is silently incorrect.

Mark Dickinson added the comment: Urk. That patch produces horrible results when comparing Fractions and Decimals: Python 2.7a0 (unknown, Mar 21 2009, 17:59:48) [GCC 4.0.1 (Apple Inc. build 5490)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from fract

[issue2531] float compared to decimal is silently incorrect.

Changes by Raymond Hettinger : -- assignee: marketdickinson -> rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsu

[issue2531] float compared to decimal is silently incorrect.

Mark Dickinson added the comment: On the other hand, if it's true that mixed-type comparisons are generally followed by mixed-type arithmetic, then these comparisons just become a roundabout way to raise TypeError, which is what everybody wanted in the first place. :-) The patch still needs

[issue2531] float compared to decimal is silently incorrect.

Mark Dickinson added the comment: Here's a patch. I'm still not 100% convinced this is a good idea. Part of my objection is that it seems likely that these comparisons are fairly useless, in that a mixed-type comparison is probably going to be followed by a mixed-type arithmetic operation a

[issue2531] float compared to decimal is silently incorrect.

Raymond Hettinger added the comment: It's not a priority for me though it's not an unreasonable thing to do. A basic 5th grade exercise is ordering fractions, sometimes with their decimal equivalents:Fraction(1,3) < Decimal('0.4') < Fraction(1,2). I don't care if that gets done. If you

[issue2531] float compared to decimal is silently incorrect.

Mark Dickinson added the comment: What about Decimal <-> Fraction comparisons? -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue2531] float compared to decimal is silently incorrect.

Raymond Hettinger added the comment: The next to last sentence should have read "and, we are not obliged to carry that over to 3.x where cross-type ordering comparisons are not the norm unless a type has specifically enabled them." The gist of the idea is that in 2.x, we do have cross-type orde

[issue2531] float compared to decimal is silently incorrect.

Raymond Hettinger added the comment: I think "the best we can do" is return valid comparison results between floats and decimals in 2.x. It doesn't make anything worse and it does make something better. Unlike other cross-type comparisons, number-to-number is not an unreasonable thing to do.

[issue2531] float compared to decimal is silently incorrect.

Mark Dickinson added the comment: > My complaint is that it is silently wrong. I appreciate that, but I don't see any good solution. Yes, it would be nice if float <-> Decimal comparisons raised TypeError in 2.x. But Python 2.x has an '(almost) everything is comparable to everything else'

[issue2531] float compared to decimal is silently incorrect.

Jeremy Dunck added the comment: I hear you on the 2.x to 3.x transition-- I'm not really asking for mixed-mode arithmetic. I'd be perfectly happy if float > decimal raised TypeError, as float + decimal does. My complaint is that it is silently wrong. -- __

[issue2531] float compared to decimal is silently incorrect.

Mark Dickinson added the comment: Making float <-> Decimal comparisons return the 'right' answer in 2.x does look attractive at first sight, but the more I think about it the more it seems a bad idea. Having the comparisons work in 2.x but not in 3.x seems especially nasty, and allowing mixe

[issue2531] float compared to decimal is silently incorrect.

Raymond Hettinger added the comment: Imri, I don't think the 3.0 model for cross-type comparisons can be backported without breaking code, so it probably isn't going to happen. The whole purpose of the 3.x series was to allow improvements that weren't backwards compatible. Mark, this raises a

[issue2531] float compared to decimal is silently incorrect.

Imri Goldberg added the comment: This behavior also exists in Python 2.6. However, in Python 3 an exception is raised instead, as these kinds of comparisons are considered incorrect. Because of that, I'd like Python 3's behavior of raising exceptions on float-decimal comparisons to be backported

[issue2531] float compared to decimal is silently incorrect.

Facundo Batista <[EMAIL PROTECTED]> added the comment: Which version of 2.4 are you talking about? This line in the tests... self.assertNotEqual(da, 32.7) is there since almost 4 years ago (release 36325, and 2.4 is tagged in release 37906). Anyway, this behaviour is ok, as is the following

[issue2531] float compared to decimal is silently incorrect.

Changes by Jeremy Dunck <[EMAIL PROTECTED]>: -- type: -> behavior __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscr

[issue2531] float compared to decimal is silently incorrect.

Changes by Diego Manenti Martins <[EMAIL PROTECTED]>: -- keywords: +patch versions: +Python 2.6 Added file: http://bugs.python.org/file9922/decimal.patch __ Tracker <[EMAIL PROTECTED]> __

[issue2531] float compared to decimal is silently incorrect.

New submission from Jeremy Dunck <[EMAIL PROTECTED]>: Within python 2.5.2: >>> from decimal import Decimal >>> x = 3.0 >>> y = Decimal('0.25') >>> x > y False (expected error, as in 2.4, or True) -- components: Library (Lib) messages: 64827 nosy: jdunck severity: normal status: open tit