In article [EMAIL PROTECTED],
Steven D'Aprano [EMAIL PROTECTED] wrote:
On Thu, 24 Jan 2008 13:34:56 +, Antoon Pardon wrote:
On 2008-01-21, Steven D'Aprano [EMAIL PROTECTED]
wrote:
On Sun, 20 Jan 2008 21:15:02 -0600, Albert Hopkins wrote:
According to the IEEE-754 standard the usual
On 2008-01-25, Steven D'Aprano [EMAIL PROTECTED] wrote:
On Fri, 25 Jan 2008 07:57:13 +, Antoon Pardon wrote:
But if you consider that having x is not smaller than y be equivalent
to x is greater than or equal to y is more important than forcing a
boolean answer in the first place, then
On Jan 28, 6:50 am, Antoon Pardon [EMAIL PROTECTED] wrote:
My personal preference would be that python would allow people the
choice, with the default being that any operation that resulted
in a non numeric result would throw an exception.
People who somehow made it clear they know how to
On Jan 28, 6:50 am, Antoon Pardon [EMAIL PROTECTED] wrote:
People who somehow made it clear they know how to work with inf, and
NaN results, would get silent NaN where no exceptions would be thrown.
One other thing: there's an excellent starting point for considering
how things should work, in
Mark Dickinson [EMAIL PROTECTED] writes:
Any change to Python that made == and != checks involving NaNs raise
an exception would have to consider the consequences for set, dict,
list membership testing.
and if Python had separate operators for these two purposes it
wouldn't be Python
On 2008-01-24, Steven D'Aprano [EMAIL PROTECTED] wrote:
On Thu, 24 Jan 2008 13:34:56 +, Antoon Pardon wrote:
On 2008-01-21, Steven D'Aprano [EMAIL PROTECTED]
wrote:
On Sun, 20 Jan 2008 21:15:02 -0600, Albert Hopkins wrote:
According to the IEEE-754 standard the usual trichotomy of x is
On Fri, 25 Jan 2008 07:57:38 +, Pete Forman wrote:
Mark Dickinson [EMAIL PROTECTED] writes:
Any change to Python that made == and != checks involving NaNs raise
an exception would have to consider the consequences for set, dict,
list membership testing.
[…]
and if Python had
On Fri, 25 Jan 2008 07:57:13 +, Antoon Pardon wrote:
But if you consider that having x is not smaller than y be equivalent
to x is greater than or equal to y is more important than forcing a
boolean answer in the first place, then you need something to signal
Undefined, and an exception
Marc 'BlackJack' Rintsch wrote:
On Fri, 25 Jan 2008 07:57:38 +, Pete Forman wrote:
Mark Dickinson [EMAIL PROTECTED] writes:
Any change to Python that made == and != checks involving NaNs raise
an exception would have to consider the consequences for set, dict,
list membership
On 2008-01-21, Steven D'Aprano [EMAIL PROTECTED] wrote:
On Sun, 20 Jan 2008 21:15:02 -0600, Albert Hopkins wrote:
According to the IEEE-754 standard the usual trichotomy of x is less
than y, x is equal to y, or x is greater than y has to be extended to
include x and y are unordered.
Antoon Pardon wrote:
That doesn't follow. The problem is not that x nan returns False
because that is correct since x isn't smaller than nan. The problem
is cmp(x, nan) returning 1, because that indicates that x is greater
than nan and that isn't true.
Please report the problem. cmp(),
On Jan 24, 2:28 pm, Christian Heimes [EMAIL PROTECTED] wrote:
Antoon Pardon wrote:
That doesn't follow. The problem is not that x nan returns False
because that is correct since x isn't smaller than nan. The problem
is cmp(x, nan) returning 1, because that indicates that x is greater
Christian Heimes [EMAIL PROTECTED] writes:
Antoon Pardon wrote:
That doesn't follow. The problem is not that x nan returns False
because that is correct since x isn't smaller than nan. The problem
is cmp(x, nan) returning 1, because that indicates that x is greater
than nan and that isn't
On Thu, 24 Jan 2008 13:34:56 +, Antoon Pardon wrote:
On 2008-01-21, Steven D'Aprano [EMAIL PROTECTED]
wrote:
On Sun, 20 Jan 2008 21:15:02 -0600, Albert Hopkins wrote:
According to the IEEE-754 standard the usual trichotomy of x is less
than y, x is equal to y, or x is greater than y has
On Thu, 24 Jan 2008 16:51:16 +, Pete Forman wrote:
Christian Heimes [EMAIL PROTECTED] writes:
Antoon Pardon wrote:
That doesn't follow. The problem is not that x nan returns False
because that is correct since x isn't smaller than nan. The problem is
cmp(x, nan) returning 1, because
On Jan 24, 7:09 pm, Steven D'Aprano [EMAIL PROTECTED]
cybersource.com.au wrote:
I'm having a lot of trouble finding the canonical IEEE-754 standard, so
I'm forced to judge by implementations and third party accounts. For
example, this is what IBM says:
There's a recent draft of IEEE 754r (the
Jason wrote:
Please note that NaN's are very funky and platform dependent. They
depend on their underlying platform's C library for creation and
display. On windows, float('nan') will cause an exception, as there
are no valid string representations of NAN that can be converted to
the
Grant Edwards wrote:
In many applications (e.g. process control) propogating NaN
values are way too useful to avoid. Avoiding NaN would make a
lot of code far more complicated than would using them.
NaNs are very useful for experienced power users but they are very
confusing for newbies or
In article [EMAIL PROTECTED],
Christian Heimes [EMAIL PROTECTED] wrote:
Grant Edwards wrote:
In many applications (e.g. process control) propogating NaN
values are way too useful to avoid. Avoiding NaN would make a
lot of code far more complicated than would using them.
NaNs are very
Russell E. Owen wrote:
In article [EMAIL PROTECTED],
Christian Heimes [EMAIL PROTECTED] wrote:
Grant Edwards wrote:
In many applications (e.g. process control) propogating NaN
values are way too useful to avoid. Avoiding NaN would make a
lot of code far more complicated than would using
On Sun, 20 Jan 2008 21:15:02 -0600, Albert Hopkins wrote:
This issue may have been referred to in
news:[EMAIL PROTECTED] but I didn't
entirely understand the explanation. Basically I have this:
a = float(6)
b = float('nan')
min(a, b)
6.0
min(b, a)
nan
On Jan 21, 12:00 am, Albert Hopkins [EMAIL PROTECTED] wrote:
On Sun, 20 Jan 2008 20:16:18 -0800, Paddy wrote:
I am definitely NOT a floating point expert, but I did find this:
http://en.wikipedia.org/wiki/IEEE_754r#min_and_max
P.S. What platform /Compiler are you using for Python?
Linux
On Jan 21, 9:55 am, Jason [EMAIL PROTECTED] wrote:
display. On windows, float('nan') will cause an exception, as there
are no valid string representations of NAN that can be converted to
the special floating point value. Also, if you manage to create a nan
under Windows, it displays as
On 2008-01-21, Albert Hopkins [EMAIL PROTECTED] wrote:
This issue may have been referred to in
news:[EMAIL PROTECTED] but I didn't
entirely understand the explanation. Basically I have this:
a = float(6)
b = float('nan')
min(a, b)
6.0
min(b, a)
nan
On 2008-01-21, Jason [EMAIL PROTECTED] wrote:
Infinite values are also problematic. In almost all cases, it is far
better to avoid infinite and NaN values.
In many applications (e.g. process control) propogating NaN
values are way too useful to avoid. Avoiding NaN would make a
lot of code
Grant Edwards [EMAIL PROTECTED] writes:
For applications I work on, it should be NaN. But I think the
result of comparing a Normal to a NaN is undefined, so the
above behavior is allowed by the IEEE spec.
Comparison of two floating point datums results in exactly one of
these being true:
On Mon, 21 Jan 2008 18:00:05 +, Pete Forman wrote:
If NaNs in your data are important then you must take care in explicit
and implicit comparisons to consider unordered results.
And even if they're not important, beware of bugs from failing to
consider unordered results due to unexpected
This issue may have been referred to in
news:[EMAIL PROTECTED] but I didn't
entirely understand the explanation. Basically I have this:
a = float(6)
b = float('nan')
min(a, b)
6.0
min(b, a)
nan
max(a, b)
6.0
max(b, a)
nan
Before I did not know
'NaN' means Not a number. according to Python semantics, if you try
to compare it with any other float numbers, it should return FALSE.
just like
1.0 'abc'
False
Since it always return FALSE, it is not a surprise for your question.
If you wish to get infinitive number, you'd use 'inf' or
'NaN' means Not a number. according to Python semantics, if you try
to compare it with any other float numbers, it should return FALSE.
just like:
1.0 'abc'
False
Since it always return FALSE, it is not a surprise for your question.
If you wish to get infinitive number, you'd use
On Jan 21, 3:15 am, Albert Hopkins [EMAIL PROTECTED] wrote:
This issue may have been referred to in
news:[EMAIL PROTECTED] but I didn't
entirely understand the explanation. Basically I have this:
a = float(6)
b = float('nan')
min(a, b)
6.0
min(b, a)
nan
On Sun, 20 Jan 2008 20:16:18 -0800, Paddy wrote:
I am definitely NOT a floating point expert, but I did find this:
http://en.wikipedia.org/wiki/IEEE_754r#min_and_max
P.S. What platform /Compiler are you using for Python?
Linux with GCC 4
-a
--
32 matches
Mail list logo
