Guido van Rossum wrote:
> On Tue, Mar 16, 2010 at 2:32 PM, Steven D'Aprano 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
On Sat, Mar 20, 2010 at 4:38 PM, Mark Dickinson wrote:
> On Sat, Mar 20, 2010 at 7:56 PM, Guido van Rossum 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 hav
On Sat, Mar 20, 2010 at 7:56 PM, Guido van Rossum 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 convert floats a
On Sat, Mar 20, 2010 at 4:16 AM, Mark Dickinson 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 inputs (regardl
On Sat, Mar 20, 2010 at 10:05 AM, Mark Dickinson wrote:
> On Sat, Mar 20, 2010 at 3:17 PM, Case Vanhorsen wrote:
>> On Sat, Mar 20, 2010 at 4:06 AM, Mark Dickinson wrote:
>>> What external modules are there that rely on existing hash behaviour?
>>
>> I'm only aware of gmpy and SAGE.
>>
>>> And
On Sat, Mar 20, 2010 at 3:17 PM, Case Vanhorsen wrote:
> On Sat, Mar 20, 2010 at 4:06 AM, Mark Dickinson 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?
>
> Instead of calculatin
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
On Sat, Mar 20, 2010 at 4:06 AM, Mark Dickinson wrote:
> On Fri, Mar 19, 2010 at 1:17 PM, Case Vanhorsen wrote:
>> On Fri, Mar 19, 2010 at 3:07 AM, Mark Dickinson wrote:
>>> On Fri, Mar 19, 2010 at 9:37 AM, Mark Dickinson wrote:
Making hashes of int,
float, Decimal *and* Fraction all
On Sat, Mar 20, 2010 at 12:10 AM, Greg Ewing
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 our rational types
On Fri, Mar 19, 2010 at 1:17 PM, Case Vanhorsen wrote:
> On Fri, Mar 19, 2010 at 3:07 AM, Mark Dickinson wrote:
>> On Fri, Mar 19, 2010 at 9:37 AM, Mark Dickinson wrote:
>>> Making hashes of int,
>>> float, Decimal *and* Fraction all compatible with one another,
>>> efficient for ints and floats
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 the
Guido van Rossum python.org> writes:
>
> Antoine, I think your email client turns replies whose subject
> contains '&' into new subjects containing sequences like this:
>
> & amp; lt; -& amp; gt;
>
> There's a number of new threads with ever-more occurrences of "amp" in
> the subject,
On Thu, Mar 18, 2010 at 12:41, Mark Dickinson 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 my earlier pos
On Fri, Mar 19, 2010 at 3:07 AM, Mark Dickinson wrote:
> On Fri, Mar 19, 2010 at 9:37 AM, Mark Dickinson 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, i
Mark Dickinson wrote:
> On Fri, Mar 19, 2010 at 9:37 AM, Mark Dickinson 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, hash(n)
> == n, as
On Fri, Mar 19, 2010 at 9:37 AM, Mark Dickinson 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 of how it cou
On Thu, Mar 18, 2010 at 9:48 PM, Nick Coghlan 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, dec(1))) ==
On 3/18/2010 6:18 PM, Antoine Pitrou wrote:
Glenn Linderman g.nevcal.com> writes:
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 wa
Glenn Linderman g.nevcal.com> writes:
>
> 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 behavi
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 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 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
com
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.
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
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 qu
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, i
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 f
On 18/03/2010 18:44, Antoine Pitrou wrote:
[snip...]
Seems like it would be better to raise an exception, and in the
documentation for the exception point out that turning off the exception
(if it should be decided that that should be possible, which could be
good for compatibility), would regre
Glenn Linderman g.nevcal.com> writes:
>
> For all the reasons that mixed decimal and float arithmetic is bad,
> mixed decimal and float comparisons are also bad. To do proper
> comparisons, you need to know the number of significant digits of both
> numbers, and the precision and numeric rang
On Thu, Mar 18, 2010 at 5:55 PM, Raymond Hettinger
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 x (or the user simply doesn't understand what his or her code is
> actually doing). That us
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 give
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
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
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 exce
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 (r254:
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 r
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 minimum-d
On Wed, Mar 17, 2010 at 1:44 PM, Raymond Hettinger
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 options from worst
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
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, sur
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 i
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 g
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 im
On Wed, Mar 17, 2010 at 8:04 AM, Mark Dickinson wrote:
> On Tue, Mar 16, 2010 at 5:15 PM, Guido van Rossum 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 *
On Tue, Mar 16, 2010 at 5:15 PM, Guido van Rossum 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 of situations
On Wed, Mar 17, 2010 at 11:43 AM, Steven D'Aprano 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 enough for intege
On Wed, Mar 17, 2010 at 12:36 AM, Raymond Hettinger
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 should also be ruled o
On Tue, Mar 16, 2010 at 10:32 PM, Steven D'Aprano wrote:
> On Wed, 17 Mar 2010 03:23:30 am Mark Dickinson wrote:
>> On Tue, Mar 16, 2010 at 4:11 PM, Mark Dickinson
>> wrote: [...]
>>
>> Decimal.from_float(1.1) == 1.1
>> >
>> > False
>>
>> Whoops. To clarify, this is the pre-patch behaviour;
On Tue, Mar 16, 2010 at 10:16 PM, Greg Ewing
wrote:
> Mark Dickinson wrote:
>>
>> On Tue, Mar 16, 2010 at 3:58 PM, P.J. Eby 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-poin
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
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 thin
On Wed, 17 Mar 2010 12:27:01 pm Raymond Hettinger wrote:
> On Mar 16, 2010, at 3:16 PM, Greg Ewing wrote:
> > Seems to me that this education would mostly consist of saying
> > "don't compare floats and decimals", which is why I think that
> > disallowing them in the first place would be better.
>
On Mar 16, 2010, at 3:16 PM, Greg Ewing wrote:
>
> Seems to me that this education would mostly consist of saying
> "don't compare floats and decimals", which is why I think that
> disallowing them in the first place would be better.
That makes sense.
I do worry that 2.x currently does make the
On Tue, Mar 16, 2010 at 5:36 PM, Raymond Hettinger
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 the exception-ra
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 2:32 PM, Steven D'Aprano 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 mixed arithmeti
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
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 co
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
Decim
On Wed, 17 Mar 2010 03:23:30 am Mark Dickinson wrote:
> On Tue, Mar 16, 2010 at 4:11 PM, Mark Dickinson
> 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 for
Mark Dickinson wrote:
On Tue, Mar 16, 2010 at 3:58 PM, P.J. Eby 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 (e.g., educating the progr
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
origi
On Tue, Mar 16, 2010 at 9:07 AM, Mark Dickinson wrote:
> On Tue, Mar 16, 2010 at 4:41 PM, 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
On Tue, Mar 16, 2010 at 4:41 PM, 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.
That's also a possible solution, and the one that
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 b
On Tue, Mar 16, 2010 at 4:18 PM, Victor Stinner
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 sane, provided only that you
On Tue, Mar 16, 2010 at 4:11 PM, Mark Dickinson 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
Python-Dev@python.org
http://
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"
> app
On Tue, Mar 16, 2010 at 3:58 PM, P.J. Eby 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"
> app
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 a
On Tue, Mar 16, 2010 at 2:58 PM, Facundo Batista
wrote:
> On Tue, Mar 16, 2010 at 9:41 AM, 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
On Tue, Mar 16, 2010 at 9:41 AM, 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
70 matches
Mail list logo
