On 3/25/2010 9:35 PM, Greg Ewing wrote:
Steven D'Aprano wrote:
What do we do with Decimal? Aren't we committed to matching the
Decimal standard,
It's been pointed out that the Decimal standard only defines
some abstract operations, and doesn't mandate that they
be mapped onto any particular l
Steven D'Aprano writes:
> But unlike us, the equality operator only has a pinhole view of the
> operands. It can't distinguish between your example and this:
>
> x = float('nan')
> y = some_complex_calculation(x)
> if x == y:
> ...
>
> where y merely happens to end up with the same
I impulsively wrote:
The payload of a NaN in typical hardware implementations
is quite small, because it has to fit into the exponent
field.
...which turns out to be precisely wrong. Some day I'll
learn to wait until somebody else in the thread has checked
the facts for me before posting. :-)
Steven D'Aprano wrote:
What do we do with Decimal? Aren't we committed to matching the Decimal
standard,
It's been pointed out that the Decimal standard only defines
some abstract operations, and doesn't mandate that they
be mapped onto any particular language syntax. That gives
us enough flex
Steven D'Aprano wrote:
By analogy: the Lizard King of Russia does not exist; the Vampire Queen
of New Orleans also does not exist. We don't therefore conclude that
the Lizard King and the Vampire Queen are therefore the same person.
But it's equally invalid to say that they're *not* the
same
Curt Hagenlocher wrote:
Wait, what? I haven't been paying much attention, but this is backwards.
There are multiple representations of NaN in the IEEE encoding;
I think Nick's point is that there aren't enough bits
to give the result of every operation its own unique
NaN.
The payload of a NaN
On 3/25/2010 4:14 PM, Guido van Rossum wrote:
On Thu, Mar 25, 2010 at 12:31 PM, Glenn Linderman wrote:
It is my understand that even bit-for-bit identical NaN values will compare
unequal according to IEEE 754 rules.
I would have no problem with Python interning each encountered NaN value,
On Thu, Mar 25, 2010 at 18:57, Steven D'Aprano wrote:
> Simply put: we should treat "two unclear values are different" as more
> compelling than "two unclear values are the same" as it leads to fewer,
> smaller, errors. Consider:
>
> log(-1) = NAN # maths equality, not assignment
> log(-2) = NAN
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/26/2010 01:57 AM, Steven D'Aprano wrote:
> In fact, identity of NANs is itself an implementation quirk of
> programming languages like Python: logically, NANs don't have identity
> at all.
>
> To put it another way: all ONEs are the same ONE,
> -1 = -1
> implies log(-1) = log(-1)
Mathematically speaking this is incorrect.
x = y
implies
log(x) = log(y)
for x > 0 and y > 0
Cheers,
fijal
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubs
At 11:57 AM 3/26/2010 +1100, Steven D'Aprano wrote:
But they're not -- they're *signals* for "your calculation has gone
screwy and the result you get is garbage", so to speak. You
shouldn't even think of a specific NAN as a piece of specific
garbage, but merely a label on the *kind* of garbage
Steven D'Aprano wrote:
I'd like to turn the question around ... what algorithms are there that
rely on NaN == NaN being True?
That seems to be a straw question, since AFAIK nobody
has suggested that there are any such algorithms.
On the other hand, it has been claimed that some
algorithms exi
On Fri, 26 Mar 2010 09:45:51 am Greg Ewing wrote:
> Georg Brandl wrote:
> > Thinking of each value created by float('nan') as
> > a different nan makes sense to my naive mind, and it also explains
> > nicely the behavior present right now.
>
> Not entirely:
>
>x = float('NaN')
>y = x
>i
On Thu, 25 Mar 2010 06:26:11 am Mark Dickinson wrote:
> Here's an interesting recent blog post on this subject, from the
> creator of Eiffel:
>
> http://bertrandmeyer.com/2010/02/06/reflexivity-and-other-pillars-of-
>civilization/
Sorry, but he lost me right at the beginning when he quoted someon
On Mar 25, 2010, at 4:21 PM, Georg Brandl wrote:
> Am 25.03.2010 22:45, schrieb Greg Ewing:
>> Georg Brandl wrote:
>>> Thinking of each value created by float('nan') as
>>> a different nan makes sense to my naive mind, and it also explains
>>> nicely the behavior present right now.
>>
>> Not ent
Am 25.03.2010 22:45, schrieb Greg Ewing:
> Georg Brandl wrote:
>> Thinking of each value created by float('nan') as
>> a different nan makes sense to my naive mind, and it also explains
>> nicely the behavior present right now.
>
> Not entirely:
>
>x = float('NaN')
>y = x
>if x == y:
On Thu, Mar 25, 2010 at 12:31 PM, Glenn Linderman wrote:
> It is my understand that even bit-for-bit identical NaN values will compare
> unequal according to IEEE 754 rules.
>
> I would have no problem with Python interning each encountered NaN value, to
> avoid having bit-for-bit identical NaN va
On Thu, Mar 25, 2010 at 04:18, Steven D'Aprano wrote:
> def myfunc(x, y):
> if x == y:
> return 1.0
> else:
> return something_complicated**(x-y)
>
>
> Optimising floating point code is fraught with dangers (the above fails
> for x=y=INF as well as NAN) but anything that make N
Steven D'Aprano pearwood.info> writes:
>
> Personally, I'm less concerned about sets of floats ending up with
> strange combinations of NANs than I am about the possibility of
> disastrous maths errors caused by allowing NANs to test as equal.
> Here's a simplistic example:
You just said "if
Georg Brandl wrote:
Thinking of each value created by float('nan') as
a different nan makes sense to my naive mind, and it also explains
nicely the behavior present right now.
Not entirely:
x = float('NaN')
y = x
if x == y:
...
There it's hard to argue that the NaNs being compared
r
On Thu, 25 Mar 2010 10:25:35 pm Nick Coghlan wrote:
> Steven D'Aprano wrote:
> > I'd like to turn the question around ... what algorithms are there
> > that rely on NaN == NaN being True?
>
> Absolutely anything that expects "x is y" to imply that "x == y". The
> builtin containers enforce this by
>> I'm inclined to leave it alone unless/until Raymond or somebody else
>> steps up to really champion it.
>
> I'm okay with that.
And I am looking for another bug, that I could get some python-fu from ;-)
--
Filip Gruszczyński
___
Python-Dev mailing l
On 3/25/2010 8:13 AM, Mark Dickinson wrote:
On Thu, Mar 25, 2010 at 3:05 PM, Nick Coghlan wrote:
Mark Dickinson wrote:
On Thu, Mar 25, 2010 at 2:08 PM, Nick Coghlan wrote:
Jesus Cea wrote:
But IEEE 754 was created by pretty clever guys and sure they had a
reason
M.-A. Lemburg, 25.03.2010 10:10:
larry.hastings wrote:
Author: larry.hastings
Date: Thu Mar 25 01:54:54 2010
New Revision: 79397
Log:
Backported PyCapsule from 3.1, and converted most uses of
CObject to PyCapsule.
Backporting PyCapsule is fine, but the changes you made to all
those PyCObject
Just a reply to one part of your message, as I really need to get back
to work for now.
Antoine Pitrou wrote:
I think solution #1 would be the best one.
#2 looks too complicated.
#2 is a seven-line diff, below.
/larry/
Index: cobject.c
=
On Thu, Mar 25, 2010 at 2:16 PM, Larry Hastings wrote:
> My understanding is that requiring a recompile is okay
This has always been a point of contention. I'm not even sure what
the current official position is.
-Fred
--
Fred L. Drake, Jr.
"Chaos is the score upon which reality is wri
M.-A. Lemburg wrote:
[Y]ou're pretty much breaking all 3rd party modules that have just started
using e.g the datetime module C API.
Not if they're using PyDateTime_IMPORT. My understanding is that
requiring a recompile is okay, and if you use PyDateTime_IMPORT and
recompile against 2.7 it
Hello Larry,
> You're right, my changes aren't backwards compatible. I thought it was
> reasonable for four reasons:
>
> 1. The CObject API isn't safe. It's easy to crash Python 2.6 in just a
> few lines by mixing and matching CObjects. Switching Python to capsules
> prevents a class of ex
Larry Hastings wrote:
>
> M.-A. Lemburg wrote:
>> Backporting PyCapsule is fine, but the changes you made to all
>> those PyCObject uses does not look backwards compatible.
>>
>> The C APIs exposed by the modules (e.g. the datetime module)
>> are used in lots of 3rd party extension modules and cha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/25/2010 04:07 PM, David Cournapeau wrote:
> Yes, indeed. I don't claim having a deep understanding myself, but up
> to now, everytime I thought something in IEE 754 was weird, it ended
> up being for good reasons.
I was wondering if we could bri
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/25/2010 03:19 PM, Steven D'Aprano wrote:
> On Thu, 25 Mar 2010 11:36:28 pm Jesus Cea wrote:
>
>> Infinites are "not equal" for a good reason, for example.
>>
>> 1/0 and 2/0 are both infinites, but one is "greater" than the other.
>> Or (1/0)^(1/
M.-A. Lemburg wrote:
Backporting PyCapsule is fine, but the changes you made to all
those PyCObject uses does not look backwards compatible.
The C APIs exposed by the modules (e.g. the datetime module)
are used in lots of 3rd party extension modules and changing
them from PyCObject to PyCapsule
On Mar 25, 2010, at 4:22 AM, Nick Coghlan wrote:
> Mark Dickinson wrote:
>> Here's an interesting recent blog post on this subject, from the
>> creator of Eiffel:
>>
>> http://bertrandmeyer.com/2010/02/06/reflexivity-and-other-pillars-of-civilization/
>
> Interesting. So the natural tweak that
Nick Coghlan wrote:
Completely agree on all points. Now we're just left with "is it worth
expanding the str api for this?". I don't feel strongly either way.
For something as core as the string API, we better feel darn strongly
about it before we mess with it :)
I'm inclined to leave it alone
Nick Coghlan gmail.com> writes:
>
> For something as core as the string API, we better feel darn strongly
> about it before we mess with it :)
Having two very similar methods with different names and subtly different APIs
sounds bad IMHO.
Also, the use case doesn't look very strong to me.
> P.S
On Thu, Mar 25, 2010 at 3:05 PM, Nick Coghlan wrote:
> Mark Dickinson wrote:
>> On Thu, Mar 25, 2010 at 2:08 PM, Nick Coghlan wrote:
>>> Jesus Cea wrote:
But IEEE 754 was created by pretty clever guys and sure they had a
reason for define things in the way they are. Probably we are miss
Eric Smith wrote:
> Nick Coghlan wrote:
>> Moving the decision of "how am I going to be called" to the time of
>> writing the format string is a bit odd.
>>
>> On the other hand, the specially crafted format string does have the
>> virtue of travelling far more easily through any APIs that wrap the
On Thu, Mar 25, 2010 at 9:39 PM, Jesus Cea wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 03/25/2010 12:22 PM, Nick Coghlan wrote:
>> "Not a Number" is not a single floating point value. Instead each
>> instance is a distinct value representing the precise conditions that
>>
Mark Dickinson wrote:
> On Thu, Mar 25, 2010 at 2:08 PM, Nick Coghlan wrote:
>> Jesus Cea wrote:
>>> But IEEE 754 was created by pretty clever guys and sure they had a
>>> reason for define things in the way they are. Probably we are missing
>>> something.
>> Yes, this is where their "implementabl
On Thu, Mar 25, 2010 at 3:01 PM, Curt Hagenlocher wrote:
> On Thu, Mar 25, 2010 at 7:54 AM, Mark Dickinson wrote:
>>
>> Hmm. I take it back. I was being confused by the fact that sqrt(nan)
>> returns a nan with a new identity; but it does apparently preserve
>> the payload. An example:
>
> I p
On Thu, Mar 25, 2010 at 7:54 AM, Mark Dickinson wrote:
>
> Hmm. I take it back. I was being confused by the fact that sqrt(nan)
> returns a nan with a new identity; but it does apparently preserve
> the payload. An example:
I played with this some a few months ago, and both the FPU and the C
l
Nick Coghlan wrote:
Moving the decision of "how am I going to be called" to the time of
writing the format string is a bit odd.
On the other hand, the specially crafted format string does have the
virtue of travelling far more easily through any APIs that wrap the
basic format() method (since it
On Thu, Mar 25, 2010 at 2:42 PM, Mark Dickinson wrote:
> On Thu, Mar 25, 2010 at 2:26 PM, Antoine Pitrou wrote:
>> This sounds a bit sophistic, if the (Python) user doesn't have access to
>> the payload anyway.
>
> Well, you can get at the payload using the struct module, if you care
> enough. B
Mark Dickinson gmail.com> writes:
>
> On Thu, Mar 25, 2010 at 12:39 PM, Jesus Cea jcea.es> wrote:
> >
> > But IEEE 754 was created by pretty clever guys and sure they had a
> > reason for define things in the way they are. Probably we are missing
> > something.
>
> Well, if we are, then nobody
On Thu, Mar 25, 2010 at 2:26 PM, Antoine Pitrou wrote:
> Le Thu, 25 Mar 2010 07:19:24 -0700, Curt Hagenlocher a écrit :
>> Wait, what? I haven't been paying much attention, but this is backwards.
>> There are multiple representations of NaN in the IEEE encoding; that's
>> actually part of the prob
Le Thu, 25 Mar 2010 07:19:24 -0700, Curt Hagenlocher a écrit :
> On Thu, Mar 25, 2010 at 7:08 AM, Nick Coghlan
> wrote:
>
>> Jesus Cea wrote:
>> > But IEEE 754 was created by pretty clever guys and sure they had a
>> > reason for define things in the way they are. Probably we are missing
>> > som
On Thu, Mar 25, 2010 at 2:08 PM, Nick Coghlan wrote:
> Jesus Cea wrote:
>> But IEEE 754 was created by pretty clever guys and sure they had a
>> reason for define things in the way they are. Probably we are missing
>> something.
>
> Yes, this is where their "implementable in a hardware circuit" fo
On Thu, Mar 25, 2010 at 7:08 AM, Nick Coghlan wrote:
> Jesus Cea wrote:
> > But IEEE 754 was created by pretty clever guys and sure they had a
> > reason for define things in the way they are. Probably we are missing
> > something.
>
> Yes, this is where their "implementable in a hardware circuit
On Thu, 25 Mar 2010 11:36:28 pm Jesus Cea wrote:
> Infinites are "not equal" for a good reason, for example.
>
> 1/0 and 2/0 are both infinites, but one is "greater" than the other.
> Or (1/0)^(1/0), an infinite infinitelly "bigger".
I think you're mistaken. In Python 3.1:
>>> x = float('inf')
Eric Smith wrote:
> Considering that, maybe the best thing is to do nothing. I'll update the
> issue with this note.
I agree this slightly weakens the case for change, but it's not really
the same thing. Adding a "format_mapping" method allows an arbitrary
mapping to be used with any keyword-based
Jesus Cea wrote:
> But IEEE 754 was created by pretty clever guys and sure they had a
> reason for define things in the way they are. Probably we are missing
> something.
Yes, this is where their "implementable in a hardware circuit" focus
comes in. They were primarily thinking of a floating point
On Thu, Mar 25, 2010 at 12:39 PM, Jesus Cea wrote:
>
> But IEEE 754 was created by pretty clever guys and sure they had a
> reason for define things in the way they are. Probably we are missing
> something.
Well, if we are, then nobody seems to know what! See the Bertrand
Meyer blog post that wa
On Thu, Mar 25, 2010 at 12:36 PM, Jesus Cea wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 03/25/2010 07:54 AM, Georg Brandl wrote:
>>> float('nan') in [float('nan')]
False
>>>
>>> Sure, but just think of it as having two different nans there. (You
>>> could imagine thin
Nick Coghlan wrote:
Filip Gruszczyński wrote:
I would appreciate any advice on this topic, even if this ticket would
be dismissed altogether, as I would like to learn as much as possible
on practices on developing Python.
Raymond's use case is valid, but the currently proposed method name is
w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/25/2010 12:22 PM, Nick Coghlan wrote:
> "Not a Number" is not a single floating point value. Instead each
> instance is a distinct value representing the precise conditions that
> created it. Thus, two "NaN" values x and y will compare equa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/25/2010 07:54 AM, Georg Brandl wrote:
>> float('nan') in [float('nan')]
>>> False
>>
>> Sure, but just think of it as having two different nans there. (You
>> could imagine thinking of the id of the nan as part of the payload.)
>
> That's i
On Thu, Mar 25, 2010 at 11:22 AM, Nick Coghlan wrote:
> So, I'm specifically putting that proposal on the table for both float
> and Decimal NaNs in Python:
>
> "Not a Number" is not a single floating point value. Instead each
> instance is a distinct value representing the precise conditions th
Mark Dickinson wrote:
> +0.2 from me. I could happily live with this change; but could also
> equally live with the existing weirdness.
>
> It's still a little odd for an immutable type to care about object
> identity, but I guess oddness comes with the floating-point territory.
> :)
The trick
larry.hastings wrote:
> Author: larry.hastings
> Date: Thu Mar 25 01:54:54 2010
> New Revision: 79397
>
> Log:
> Backported PyCapsule from 3.1, and converted most uses of
> CObject to PyCapsule.
Backporting PyCapsule is fine, but the changes you made to all
those PyCObject uses does not look back
Filip Gruszczyński wrote:
From that spec, a straightforward API falls out:
def format_mapping(self, kwds):
# Method body actually written in C, so it can
# easily invoke the internal formatting operation
return do_string_format(self, NULL, kwds)
Thanks a lot for the advice, I
On Thu, Mar 25, 2010 at 11:22 AM, Nick Coghlan wrote:
> Mark Dickinson wrote:
>> Here's an interesting recent blog post on this subject, from the
>> creator of Eiffel:
>>
>> http://bertrandmeyer.com/2010/02/06/reflexivity-and-other-pillars-of-civilization/
>
> Interesting. So the natural tweak tha
> From that spec, a straightforward API falls out:
>
> def format_mapping(self, kwds):
> # Method body actually written in C, so it can
> # easily invoke the internal formatting operation
> return do_string_format(self, NULL, kwds)
Thanks a lot for the advice, I'll provide accord
Steven D'Aprano wrote:
> I'd like to turn the question around ... what algorithms are there that
> rely on NaN == NaN being True?
Absolutely anything that expects "x is y" to imply that "x == y". The
builtin containers enforce this by checking identity before they check
equality, but there are pl
Mark Dickinson wrote:
> Here's an interesting recent blog post on this subject, from the
> creator of Eiffel:
>
> http://bertrandmeyer.com/2010/02/06/reflexivity-and-other-pillars-of-civilization/
Interesting. So the natural tweak that would arise from that perspective
is for us to restore reflex
Filip Gruszczyński wrote:
> I would appreciate any advice on this topic, even if this ticket would
> be dismissed altogether, as I would like to learn as much as possible
> on practices on developing Python.
Raymond's use case is valid, but the currently proposed method name is
way too long to be
Ron Adam wrote:
> h... unless there is a __pycache__ *file* located there first. ;-)
Just a specific reason why attempting to create __pycache__ can fail
(which has defined behaviour in the PEP - running directly from the
source without caching the bytecode file).
Cheers,
Nick.
--
Nick Cogh
Steven D'Aprano wrote:
> On Thu, 25 Mar 2010 03:22:29 am Mark Dickinson wrote:
>> The obvious way to do this nan interning for floats would be to put
>> the interning code into PyFloat_FromDouble. I'm not sure whether
>> this would be worth the cost in terms of added code (and possibly
>> reduced
On Thu, 25 Mar 2010 05:26:12 am Alexander Belopolsky wrote:
> Mark, I wonder if you could describe an algorithm off the top of your
> head that relies on NaN == NaN being false.
I don't know whether "relies on" is appropriate, but consider:
def myfunc(x, y):
if x == y:
return 1.0
larry.hastings wrote:
> Author: larry.hastings
> Date: Thu Mar 25 01:54:54 2010
> New Revision: 79397
>
> Log:
> Backported PyCapsule from 3.1, and converted most uses of
> CObject to PyCapsule.
Backporting PyCapsule is fine, but the changes you made to all
those PyCObject uses does not look back
Am 24.03.2010 22:47, schrieb Mark Dickinson:
> On Wed, Mar 24, 2010 at 10:36 PM, Alexander Belopolsky
> wrote:
>> On Wed, Mar 24, 2010 at 6:31 PM, Mark Dickinson wrote:
>> ..
>>> Neither is necessary, because Python doesn't actually use == as the
>>> equivalence relation for containment testing:
70 matches
Mail list logo
