[issue2531] float compared to decimal is silently incorrect.

Mark Dickinson dicki...@gmail.com added the comment: Merged to py3k in r79668. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2531 ___

[issue2531] float compared to decimal is silently incorrect.

Mark Dickinson dicki...@gmail.com 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

[issue2531] float compared to decimal is silently incorrect.

Mark Dickinson dicki...@gmail.com 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 dicki...@gmail.com 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.

[issue2531] float compared to decimal is silently incorrect.

Changes by Vasily Ivanov b...@usagebot.com: -- nosy: +bas ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2531 ___ ___ Python-bugs-list mailing list

[issue2531] float compared to decimal is silently incorrect.

Mark Dickinson dicki...@gmail.com 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

[issue2531] float compared to decimal is silently incorrect.

Stefan Krah stefan-use...@bytereef.org 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

[issue2531] float compared to decimal is silently incorrect.

Mark Dickinson dicki...@gmail.com 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

[issue2531] float compared to decimal is silently incorrect.

Mark Dickinson dicki...@gmail.com added the comment: I'll try to find time to look at this again before 2.7 beta. -- assignee: - mark.dickinson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2531

[issue2531] float compared to decimal is silently incorrect.

Bert Hughes b.hug...@fmpco.com 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,

[issue2531] float compared to decimal is silently incorrect.

Changes by Florent Xicluna la...@yahoo.fr: -- versions: +Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2531 ___ ___ Python-bugs-list

[issue2531] float compared to decimal is silently incorrect.

Changes by Stefan Krah stefan-use...@bytereef.org: -- nosy: +skrah ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2531 ___ ___ Python-bugs-list

[issue2531] float compared to decimal is silently incorrect.

Mark Dickinson dicki...@gmail.com 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

[issue2531] float compared to decimal is silently incorrect.

Changes by Mark Dickinson dicki...@gmail.com: -- nosy: +adamtj ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2531 ___ ___ Python-bugs-list mailing

[issue2531] float compared to decimal is silently incorrect.

Raymond Hettinger rhettin...@users.sourceforge.net added the comment: Closing since no one seems interested. -- resolution: - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2531

[issue2531] float compared to decimal is silently incorrect.

Jeremy Dunck jdu...@gmail.com 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. --

[issue2531] float compared to decimal is silently incorrect.

Mark Dickinson dicki...@gmail.com added the comment: Unassigning myself. Does anyone beside Raymond and me have strong opinions about how/whether this problem should be fixed? -- ___ Python tracker rep...@bugs.python.org

[issue2531] float compared to decimal is silently incorrect.

Changes by Mark Dickinson dicki...@gmail.com: -- assignee: marketdickinson - ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2531 ___ ___

[issue2531] float compared to decimal is silently incorrect.

Mark Dickinson dicki...@gmail.com added the comment: On Fri, Apr 17, 2009 at 3:45 AM, Raymond Hettinger rep...@bugs.python.org 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

[issue2531] float compared to decimal is silently incorrect.

Raymond Hettinger rhettin...@users.sourceforge.net 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 rep...@bugs.python.org

[issue2531] float compared to decimal is silently incorrect.

Mark Dickinson dicki...@gmail.com 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 !=. --

[issue2531] float compared to decimal is silently incorrect.

Raymond Hettinger rhettin...@users.sourceforge.net added the comment: Mark, any thoughts? I would like to apply this patch for ordering comparisons other than __eq__ and __ne__. -- ___ Python tracker rep...@bugs.python.org

[issue2531] float compared to decimal is silently incorrect.

Raymond Hettinger rhettin...@users.sourceforge.net 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

[issue2531] float compared to decimal is silently incorrect.

Changes by Raymond Hettinger rhettin...@users.sourceforge.net: -- assignee: rhettinger - marketdickinson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2531 ___

[issue2531] float compared to decimal is silently incorrect.

Mark Dickinson dicki...@gmail.com 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

[issue2531] float compared to decimal is silently incorrect.

Raymond Hettinger rhettin...@users.sourceforge.net 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

[issue2531] float compared to decimal is silently incorrect.

Raymond Hettinger rhettin...@users.sourceforge.net 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

[issue2531] float compared to decimal is silently incorrect.

Mark Dickinson dicki...@gmail.com added the comment: What about Decimal - Fraction comparisons? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2531 ___

[issue2531] float compared to decimal is silently incorrect.

Raymond Hettinger rhettin...@users.sourceforge.net 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

[issue2531] float compared to decimal is silently incorrect.

Mark Dickinson dicki...@gmail.com 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

[issue2531] float compared to decimal is silently incorrect.

Mark Dickinson dicki...@gmail.com 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

[issue2531] float compared to decimal is silently incorrect.

Changes by Raymond Hettinger rhettin...@users.sourceforge.net: -- assignee: marketdickinson - rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2531 ___

[issue2531] float compared to decimal is silently incorrect.

Mark Dickinson dicki...@gmail.com 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.

[issue2531] float compared to decimal is silently incorrect.

Mark Dickinson dicki...@gmail.com 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 rep...@bugs.python.org

[issue2531] float compared to decimal is silently incorrect.

Raymond Hettinger rhettin...@users.sourceforge.net added the comment: I'll look at this more later today. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2531 ___

[issue2531] float compared to decimal is silently incorrect.

Mark Dickinson dicki...@gmail.com 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,

[issue2531] float compared to decimal is silently incorrect.

Jeremy Dunck jdu...@gmail.com 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.

Raymond Hettinger rhettin...@users.sourceforge.net 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

[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.

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 title: float

[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] http://bugs.python.org/issue2531 __

[issue2531] float compared to decimal is silently incorrect.

Changes by Jeremy Dunck [EMAIL PROTECTED]: -- type: - behavior __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2531 __ ___ Python-bugs-list mailing list Unsubscribe: