Guido van Rossum wrote:
On Tue, Mar 16, 2010 at 2:32 PM, Steven D'Aprano st...@pearwood.info wrote:
But mixed arithmetic runs into the problem, what do you want the result
type to be? Given (say) decimal+float, returning either a Decimal or a
float will be the wrong thing to do some of the
On Sat, Mar 20, 2010 at 4:38 PM, Mark Dickinson dicki...@gmail.com wrote:
On Sat, Mar 20, 2010 at 7:56 PM, Guido van Rossum gu...@python.org wrote:
I propose to reduce all hashes to the hash of a normalized fraction,
which we can define as a combination of the hashes for the numerator
and the
On Fri, Mar 19, 2010 at 1:17 PM, Case Vanhorsen cas...@gmail.com wrote:
On Fri, Mar 19, 2010 at 3:07 AM, Mark Dickinson dicki...@gmail.com wrote:
On Fri, Mar 19, 2010 at 9:37 AM, Mark Dickinson dicki...@gmail.com wrote:
Making hashes of int,
float, Decimal *and* Fraction all compatible with
On Sat, Mar 20, 2010 at 12:10 AM, Greg Ewing
greg.ew...@canterbury.ac.nz wrote:
Nick Coghlan wrote:
Mark Dickinson wrote:
It seems to me that given the existing conflation of numeric equivalence
and containment testing, going the whole hog and fixing the set
membership problem for all of
On Sat, Mar 20, 2010 at 4:06 AM, Mark Dickinson dicki...@gmail.com wrote:
On Fri, Mar 19, 2010 at 1:17 PM, Case Vanhorsen cas...@gmail.com wrote:
On Fri, Mar 19, 2010 at 3:07 AM, Mark Dickinson dicki...@gmail.com wrote:
On Fri, Mar 19, 2010 at 9:37 AM, Mark Dickinson dicki...@gmail.com wrote:
On 3/20/2010 7:06 AM, Mark Dickinson wrote:
Will this change the result of hashing a long? I know that both gmpy
and SAGE use their own hash implementations for performance reasons. I
understand that CPython's hash function is an implementation detail,
but there are external modules that rely
On Sat, Mar 20, 2010 at 3:17 PM, Case Vanhorsen cas...@gmail.com wrote:
On Sat, Mar 20, 2010 at 4:06 AM, Mark Dickinson dicki...@gmail.com wrote:
What external modules are there that rely on existing hash behaviour?
I'm only aware of gmpy and SAGE.
And exactly what behaviour do they rely
On Sat, Mar 20, 2010 at 10:05 AM, Mark Dickinson dicki...@gmail.com wrote:
On Sat, Mar 20, 2010 at 3:17 PM, Case Vanhorsen cas...@gmail.com wrote:
On Sat, Mar 20, 2010 at 4:06 AM, Mark Dickinson dicki...@gmail.com wrote:
What external modules are there that rely on existing hash behaviour?
On Sat, Mar 20, 2010 at 4:16 AM, Mark Dickinson dicki...@gmail.com wrote:
True. The reason I was concentrating on the hashes is that it's not
immediately obvious that it's even *possible* to find a decent hash
function that's efficient to compute and gives equal results for
numerically equal
On Sat, Mar 20, 2010 at 7:56 PM, Guido van Rossum gu...@python.org wrote:
I propose to reduce all hashes to the hash of a normalized fraction,
which we can define as a combination of the hashes for the numerator
and the denominator. Then all we have to do is figure fairly efficient
ways to
On Thu, Mar 18, 2010 at 9:48 PM, Nick Coghlan ncogh...@gmail.com wrote:
Note that even in Py3k there are some fairly serious weirdnesses kicking
around due to the intransitive nature of numeric equality though:
Yep. My personal favourite is:
from decimal import Decimal as dec
set((1, 1.0,
On Fri, Mar 19, 2010 at 9:37 AM, Mark Dickinson dicki...@gmail.com wrote:
Making hashes of int,
float, Decimal *and* Fraction all compatible with one another,
efficient for ints and floats, and not grossly inefficient for
Fractions and Decimals, is kinda hairy, though I have a couple of
ideas
Mark Dickinson wrote:
On Fri, Mar 19, 2010 at 9:37 AM, Mark Dickinson dicki...@gmail.com wrote:
For ints, this hash function is almost identical to what Python
already has, except that the current int hash does a reduction modulo
2**32-1 or 2**64-1 rather than 2**31-1. For all small ints,
On Fri, Mar 19, 2010 at 3:07 AM, Mark Dickinson dicki...@gmail.com wrote:
On Fri, Mar 19, 2010 at 9:37 AM, Mark Dickinson dicki...@gmail.com wrote:
Making hashes of int,
float, Decimal *and* Fraction all compatible with one another,
efficient for ints and floats, and not grossly inefficient
On Thu, Mar 18, 2010 at 12:41, Mark Dickinson dicki...@gmail.com wrote:
I'm only seeing two arguments against this at the moment: (1) it has
the potential to break code that relies on being able to sort
heterogeneous lists. But given that heterogeneous lists can't be
sorted stably anyway (see
Guido van Rossum guido at python.org writes:
Antoine, I think your email client turns replies whose subject
contains '' into new subjects containing sequences like this:
amp;amp; amp; lt; -amp;amp; amp; gt;
There's a number of new threads with ever-more occurrences of amp in
the
Nick Coghlan wrote:
Mark Dickinson wrote:
It seems to me that given the existing conflation of numeric equivalence
and containment testing, going the whole hog and fixing the set
membership problem for all of our rational types would be the right
thing to do.
Isn't this only solving half
On Thu, 18 Mar 2010 08:58:25 am Raymond Hettinger wrote:
On Mar 17, 2010, at 1:59 PM, Steven D'Aprano wrote:
On Thu, 18 Mar 2010 07:44:21 am Raymond Hettinger wrote:
The spectrum of options from worst to best is
1) compare but give the wrong answer
2) compare but give the right answer
On Mar 18, 2010, at 5:23 AM, Steven D'Aprano wrote:
On Thu, 18 Mar 2010 08:58:25 am Raymond Hettinger wrote:
On Mar 17, 2010, at 1:59 PM, Steven D'Aprano wrote:
On Thu, 18 Mar 2010 07:44:21 am Raymond Hettinger wrote:
The spectrum of options from worst to best is
1) compare but give the
On 3/18/2010 5:23 AM, Steven D'Aprano wrote:
On Thu, 18 Mar 2010 08:58:25 am Raymond Hettinger wrote:
On Mar 17, 2010, at 1:59 PM, Steven D'Aprano wrote:
On Thu, 18 Mar 2010 07:44:21 am Raymond Hettinger wrote:
The spectrum of options from worst to best is
1) compare but
On Thu, Mar 18, 2010 at 5:55 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
My thought is that intentional mixed compares of float and decimal
are very rare relative to unintentional cases. IOW, most of the
time that xy makes a float/decimal comparison, it is actually an error
(or
On Fri, 19 Mar 2010 05:41:08 am Mark Dickinson wrote:
I'd really like to get this sorted for 2.7: as far as I'm concerned,
either of the proposed behaviours (raise an exception, or allow
comparisons) would be an improvement on the current 2.7 behaviour.
Could everyone live with making
On Fri, 19 Mar 2010 05:27:06 am Glenn Linderman wrote:
Do you envisage any problems from allowing this instead?
Decimal('1.1') 2.2
True
Yes.
As any non-naïve float user is aware, the proper form of float
comparisons is not to use or or == or !=, but rather, instead of
using
On 2010-03-18 13:27 PM, Glenn Linderman wrote:
As any non-naïve float user is aware, the proper form of float
comparisons is not to use or or == or !=, but rather, instead of
using (to follow along with your example), one should use:
Decimal('1.1') - 2.2 epsilon
Not at all. This is quite
On 3/18/2010 12:45 PM, Robert Kern wrote:
On 2010-03-18 13:27 PM, Glenn Linderman wrote:
As any non-naïve float user is aware, the proper form of float
comparisons is not to use or or == or !=, but rather, instead of
using (to follow along with your example), one should use:
Decimal('1.1')
Mark Dickinson wrote:
Could everyone live with making float-Decimal comparisons raise an
exception in 2.7?
I could, with the caveat that *if* this causes problems for real world
code, then changing it to produce the correct answer (as per your patch)
should be applied as a bug fix in both 2.7
On 3/18/2010 12:34 PM, Steven D'Aprano wrote:
On Fri, 19 Mar 2010 05:27:06 am Glenn Linderman wrote:
Do you envisage any problems from allowing this instead?
Decimal('1.1') 2.2
True
Yes.
As any non-naïve float user is aware, the proper form of float
On 3/18/2010 2:48 PM, Nick Coghlan wrote:
When there is a clear, correct way (based on Decimal.from_float) to make
numeric comparison behave in accordance with the rules of mathematics,
do we really want to preserve strange, unintuitive behaviour like the above?
Cheers,
Nick.
I'm aware of
On 3/18/2010 5:48 PM, Nick Coghlan wrote:
Mark Dickinson wrote:
Could everyone live with making float-Decimal comparisons raise an
exception in 2.7?
I could, with the caveat that *if* this causes problems for real world
code, then changing it to produce the correct answer (as per your patch)
On Wed, 17 Mar 2010 10:01:12 am Guido van Rossum wrote:
On Tue, Mar 16, 2010 at 2:32 PM, Steven D'Aprano st...@pearwood.info
wrote:
But mixed arithmetic runs into the problem, what do you want the
result type to be? Given (say) decimal+float, returning either a
Decimal or a float will be
On Tue, Mar 16, 2010 at 10:16 PM, Greg Ewing
greg.ew...@canterbury.ac.nz wrote:
Mark Dickinson wrote:
On Tue, Mar 16, 2010 at 3:58 PM, P.J. Eby p...@telecommunity.com wrote:
If not, it might be confusing if a number that prints as '.1' compares
unequal to Decimal('.1').
Agreed, but this is
On Tue, Mar 16, 2010 at 10:32 PM, Steven D'Aprano st...@pearwood.info wrote:
On Wed, 17 Mar 2010 03:23:30 am Mark Dickinson wrote:
On Tue, Mar 16, 2010 at 4:11 PM, Mark Dickinson dicki...@gmail.com
wrote: [...]
Decimal.from_float(1.1) == 1.1
False
Whoops. To clarify, this is the
On Wed, Mar 17, 2010 at 12:36 AM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
On Mar 16, 2010, at 9:41 AM, Guido van Rossum wrote:
Also supporting comparisons but not other mixed operations is going to
be confusing. If you are sticking to that behavior I think mixed
comparisons
On Wed, Mar 17, 2010 at 11:43 AM, Steven D'Aprano st...@pearwood.info wrote:
Having said all that, I've just re-read the PEP, and spotted a fly in
the ointment... hash.
If we allow Decimals to compare equal to floats, that presumably implies
that they need to hash equal. That may be simple
On Tue, Mar 16, 2010 at 5:15 PM, Guido van Rossum gu...@python.org wrote:
Definitely some. Stricter comparison rules are a frequent cause of
problems when code is first ported to 3.x. While you'd think that code
comparing a float and a Decimal is *already* broken, there's a
surprising number
On Wed, Mar 17, 2010 at 8:04 AM, Mark Dickinson dicki...@gmail.com wrote:
On Tue, Mar 16, 2010 at 5:15 PM, Guido van Rossum gu...@python.org wrote:
Definitely some. Stricter comparison rules are a frequent cause of
problems when code is first ported to 3.x. While you'd think that code
On 3/17/2010 1:09 PM, Guido van Rossum wrote:
Ok, I'll try to stay out of the discussion of which solution is best
of our users, and if the outcome is that mixed operations in general
are bad but mixed comparisons are good, I'll trust you. However I want
to reiterate that you really shouldn't
On Mar 17, 2010, at 12:34 PM, Terry Reedy wrote:
I agree. Improving 2.7 and not 3.2+ would give people a reason to not move to
3.x.
FWIW, I think this is mischaracterizing the proposal.
The spectrum of options from worst to best is
1) compare but give the wrong answer
2) compare but give
On Thu, 18 Mar 2010 07:44:21 am Raymond Hettinger wrote:
The spectrum of options from worst to best is
1) compare but give the wrong answer
2) compare but give the right answer
3) refuse to compare.
Why is 3 the best? If there is a right answer to give, surely giving the
right answer it is
Steven D'Aprano wrote:
On Thu, 18 Mar 2010 07:44:21 am Raymond Hettinger wrote:
The spectrum of options from worst to best is
1) compare but give the wrong answer
2) compare but give the right answer
3) refuse to compare.
Why is 3 the best? If there is a right answer to give, surely giving
On Mar 17, 2010, at 1:59 PM, Steven D'Aprano wrote:
On Thu, 18 Mar 2010 07:44:21 am Raymond Hettinger wrote:
The spectrum of options from worst to best is
1) compare but give the wrong answer
2) compare but give the right answer
3) refuse to compare.
Why is 3 the best? If there is a
On Wed, Mar 17, 2010 at 1:44 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
On Mar 17, 2010, at 12:34 PM, Terry Reedy wrote:
I agree. Improving 2.7 and not 3.2+ would give people a reason to not move
to 3.x.
FWIW, I think this is mischaracterizing the proposal.
The spectrum of
Steven D'Aprano wrote:
More explicit than someDecimal == someFloat? Seems pretty explicit to
me.
Yes. I mean at least specifying either float(someDecimal) == someFloat
or someDecimal == Decimal(someFloat). Preferably also whether the
conversion is to be as exact as possible or on a
Guido van Rossum wrote:
in some
intuitive complexity sense an int is a simpler type than a float and
a float is a simpler type than a Decimal
I don't think this analogy holds. In a mathematical sense,
ints are a subset of reals, but binary and decimal floats
are just alternative approximate
Raymond Hettinger wrote:
Python 3 doesn't need it because it is possible to not give a result
at all. Python 2 does need it because we have to give *some*
result.
That's not true -- it's possible for comparisons to raise
an exception in 2.x, and they sometimes do already:
Python 2.5.4
On Mar 17, 2010, at 5:02 PM, Greg Ewing wrote:
Raymond Hettinger wrote:
Python 3 doesn't need it because it is possible to not give a result
at all. Python 2 does need it because we have to give *some*
result.
That's not true -- it's possible for comparisons to raise
an exception in
On Tue, Mar 16, 2010 at 9:41 AM, Mark Dickinson dicki...@gmail.com wrote:
On the one hand there's something to be said for maintaining a clean
separation between the float and Decimal types, allowing only explicit
conversions from one to the other; mixed-type arithmetic between
floats and
On Tue, Mar 16, 2010 at 2:58 PM, Facundo Batista
facundobati...@gmail.com wrote:
On Tue, Mar 16, 2010 at 9:41 AM, Mark Dickinson dicki...@gmail.com wrote:
On the one hand there's something to be said for maintaining a clean
separation between the float and Decimal types, allowing only explicit
At 09:58 AM 3/16/2010 -0500, Facundo Batista wrote:
I'm +0 to allow these comparisons, being Decimal(1) .3 the same as
Decimal(1) Decimal.from_float(.3)
Does Decimal.from_float() use the shortest decimal representation approach?
If not, it might be confusing if a number that prints as '.1'
On Tue, Mar 16, 2010 at 3:58 PM, P.J. Eby p...@telecommunity.com wrote:
At 09:58 AM 3/16/2010 -0500, Facundo Batista wrote:
I'm +0 to allow these comparisons, being Decimal(1) .3 the same as
Decimal(1) Decimal.from_float(.3)
Does Decimal.from_float() use the shortest decimal representation
Le mardi 16 mars 2010 16:58:22, P.J. Eby a écrit :
At 09:58 AM 3/16/2010 -0500, Facundo Batista wrote:
I'm +0 to allow these comparisons, being Decimal(1) .3 the same as
Decimal(1) Decimal.from_float(.3)
Does Decimal.from_float() use the shortest decimal representation
approach?
If
On Tue, Mar 16, 2010 at 4:11 PM, Mark Dickinson dicki...@gmail.com wrote:
[...]
Decimal.from_float(1.1) == 1.1
False
Whoops. To clarify, this is the pre-patch behaviour; post-patch,
this gives True.
Mark
___
Python-Dev mailing list
On Tue, Mar 16, 2010 at 4:18 PM, Victor Stinner
victor.stin...@haypocalc.com wrote:
If comparaison of Decimal and float can have unpredictable result, I would
suggest the same behaviour (raise an error).
Well, it's not really `unpredictable': the new behaviour is perfectly
predictable and
I'd say if you're not going to forward-port this to Python 3, it
shouldn't go into Python 2 -- in that case it would make more sense to
me to back-port the exception-raising behavior.
Also supporting comparisons but not other mixed operations is going to
be confusing. If you are sticking to that
On Tue, Mar 16, 2010 at 4:41 PM, Guido van Rossum gu...@python.org wrote:
I'd say if you're not going to forward-port this to Python 3, it
shouldn't go into Python 2 -- in that case it would make more sense to
me to back-port the exception-raising behavior.
That's also a possible solution, and
On Tue, Mar 16, 2010 at 9:07 AM, Mark Dickinson dicki...@gmail.com wrote:
On Tue, Mar 16, 2010 at 4:41 PM, Guido van Rossum gu...@python.org wrote:
I'd say if you're not going to forward-port this to Python 3, it
shouldn't go into Python 2 -- in that case it would make more sense to
me to
Mark Dickinson wrote:
On the one hand there's something to be said for maintaining a clean
separation between the float and Decimal types, allowing only explicit
conversions from one to the other; mixed-type arithmetic between
floats and Decimals was very deliberately not permitted in the
Mark Dickinson wrote:
On Tue, Mar 16, 2010 at 3:58 PM, P.J. Eby p...@telecommunity.com wrote:
If not, it might be confusing if a number that prints as '.1' compares
unequal to Decimal('.1').
Agreed, but this is just your everyday floating-point confusion, to be
dealt with by social means
On Wed, 17 Mar 2010 03:23:30 am Mark Dickinson wrote:
On Tue, Mar 16, 2010 at 4:11 PM, Mark Dickinson dicki...@gmail.com
wrote: [...]
Decimal.from_float(1.1) == 1.1
False
Whoops. To clarify, this is the pre-patch behaviour; post-patch,
this gives True.
Whew! You had me worried there
Steven D'Aprano wrote:
But no such problems arise with comparisons, which will always return a
bool, and will avoid the current ... interesting ... behaviour. In 3.1:
Decimal(1) == 1 == 1.0
True
Decimal(1) == 1.0
False
Decimal.from_float(1.0) == 1 == 1.0
True
Decimal.from_float(1.0) ==
On Wed, 17 Mar 2010 09:16:11 am Greg Ewing wrote:
Mark Dickinson wrote:
On Tue, Mar 16, 2010 at 3:58 PM, P.J. Eby p...@telecommunity.com
wrote:
If not, it might be confusing if a number that prints as '.1'
compares unequal to Decimal('.1').
Agreed, but this is just your everyday
On Tue, Mar 16, 2010 at 2:32 PM, Steven D'Aprano st...@pearwood.info wrote:
But mixed arithmetic runs into the problem, what do you want the result
type to be? Given (say) decimal+float, returning either a Decimal or a
float will be the wrong thing to do some of the time, so better to
prohibit
On Mar 16, 2010, at 9:41 AM, Guido van Rossum wrote:
I'd say if you're not going to forward-port this to Python 3, it
shouldn't go into Python 2 -- in that case it would make more sense to
me to back-port the exception-raising behavior.
Python 3 doesn't need it because it is possible to
On Tue, Mar 16, 2010 at 5:36 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
On Mar 16, 2010, at 9:41 AM, Guido van Rossum wrote:
I'd say if you're not going to forward-port this to Python 3, it
shouldn't go into Python 2 -- in that case it would make more sense to
me to back-port
64 matches
Mail list logo
