When is min(a, b) != min(b, a)?

[Albert Hopkins]

This issue may have been referred to in
news:<ma***************************************@py thon.orgbut 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 what to expect, but I certainly didn't expect
this. So my question is what is the min/max of a number and NaN or is it
not defined (for which I would have expected either an exception to be
raised or NaN returned in each case).

As a corrollary would I be able to rely on the above behavior or is it
subject to change (to fix a bug in min/max perhaps :-)?

[Bonjour]

'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 '-inf', from
IEEE 754 semantics:

>>>a=float(6)
b=float('inf')
c=float('-inf')

Albert Hopkins wrote:

This issue may have been referred to in
news:<ma***************************************@py thon.orgbut 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 what to expect, but I certainly didn't expect
this. So my question is what is the min/max of a number and NaN or is it
not defined (for which I would have expected either an exception to be
raised or NaN returned in each case).

As a corrollary would I be able to rely on the above behavior or is it
subject to change (to fix a bug in min/max perhaps :-)?

[Bonjour]

'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' for positive
infinitive or '-inf' for negative infinitive, from
IEEE 754 semantics, just like:

>>>a=float(6)
b=float('inf')
c=float('-inf')

For more information, PEP-0754 may be helpful.

[Paddy]

On Jan 21, 3:15 am, Albert Hopkins <[e-mail]:

This issue may have been referred to in
<news:ma***************************************@py thon.orgbut 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 what to expect, but I certainly didn't expect
this. So my question is what is the min/max of a number and NaN or is it
not defined (for which I would have expected either an exception to be
raised or NaN returned in each case).

As a corrollary would I be able to rely on the above behavior or is it
subject to change (to fix a bug in min/max perhaps :-)?

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?

- Paddy.

[Albert Hopkins]

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

[Jason]

On Jan 21, 12:00 am, Albert Hopkins <[e-mail]:

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

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 special floating point value. Also, if you manage to create a nan
under Windows, it displays as "1.#QNAN".

Infinite values are also problematic. In almost all cases, it is far
better to avoid infinite and NaN values.

--Jason

[Mark Dickinson]

On Jan 21, 9:55*am, Jason <[e-mail]:

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 "1.#QNAN".

I believe this will be fixed in Python 2.6 :)

Mark

[Grant Edwards]

On 2008-01-21, Jason <te***********@gmail.comwrote:

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 far more complicated than would using them.

--
Grant Edwards grante Yow! How's the wife?
at Is she at home enjoying
visi.com capitalism?

[Christian Heimes]

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 special floating point value. Also, if you manage to create a nan
under Windows, it displays as "1.#QNAN".

Infinite values are also problematic. In almost all cases, it is far
better to avoid infinite and NaN values.

CC to Python Dev

I've fixed that and enhanced the support for NaN and inf for 2.6 and
3.0. I'm working together with Mark on more NaN and inf related fixes
and he has fixed some numerical issues in the cmath module. We both hope
to get Python's math more sound and stable across platforms.

So far I got float('nan'), float('inf') and float('-inf') working on all
platforms. The math module got three new methods: isinf, isnan, copysign.

Additionally the trunk-math branch contains code for inverse hyberbolic
functions (acosh), log1p, Mark's fixes for complex math and more stuff.
For example operations on NaNs now return a NaN on all platforms (except
1**NAN which is defined as 1 and 0**NAN which is defined as 0). In 2.5
it depends on the platform whether a function raises an exception or
returns NaN.

Mark had the nice idea to introduce a thread local or global flag for
NaN support. Depending on a flag Python turns a NaN into an exception.
The feature needs a proper PEP. Maybe Mark has time to write a PEP in time.

Christian

[Christian Heimes]

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 developers without a numerical background.

It's very easy to create an inf or nan in Python:

inf = 1E+5000
ninf = -inf
nan = inf * 0.

1E5000 creates a nan because it is *much* bigger than DBL_MAX (around
1E+308). In fact it is even larger than LDBL_MAX (around 1E+4932).

Christian

[Russell E. Owen]

In article <ma************************************@python.org >,
Christian Heimes <li***@cheimes.dewrote:

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 developers without a numerical background.

It's very easy to create an inf or nan in Python:

inf = 1E+5000
ninf = -inf
nan = inf * 0.

1E5000 creates a nan because it is *much* bigger than DBL_MAX (around
1E+308). In fact it is even larger than LDBL_MAX (around 1E+4932).

Isn't it safer to use float("inf"), float("-inf") and float("nan") to
create the necessary items?

-- Russell

[Christian Heimes]

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(), min() and max() don't treat NaNs
right. I don't think that x < nan == False is the correct answer, too.
But I've to check the IEEE 754 specs. IMHO < nan and nan should raise
an exception.

Christian

[Paddy]

On Jan 24, 2:28 pm, Christian Heimes <[e-mail]:

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(), min() and max() don't treat NaNs
right. I don't think that x < nan == False is the correct answer, too.
But I've to check the IEEE 754 specs. IMHO < nan and nan should raise
an exception.

Christian

To a floating point interested layman such as I, treating not-a-number
comparisons with floats should give the same result as comparing a
fileobject (also not-a-number), with a float. Or does nan have /need a
more domain specific interpretation?

- Paddy.

[Mark Dickinson]

On Jan 24, 7:09*pm, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com.auwrote:

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 upcoming revision to IEEE
754) at

http://www.validlab.com/754R/drafts/...2007-10-05.pdf

Sections 5.11 and 5.3.1 deal with comparison predicates and the maxnum/
minnum operations, respectively.

One of the problems here is that Python's == operator is used for two
different purposes: first, for numeric comparisons (where in some
sense it's semi-reasonable for NaN == NaN to return False, or raise an
exception), and second, for structural operations like checking set or
dict membership. Most of the time there's not too much conflict here,
but while I fully expect 2 == Decimal('2.0') to return True, it still
occasionally feels funny to me that I can't have Decimal("2.0") and
the integer 2 be different keys in a dict: certainly they're
numerically equal, but they're still fundamentally different objects,
dammit!

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.

Mark
and if Python had separate operators for these two purposes it
wouldn't be Python any more.
Mark

[Pete Forman]

Mark Dickinson <di******@gmail.comwrites:

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 any more.

There are separate Python operators, "==" and "is".

The C99 standard, which Python defers to for its implementation, says
in 6.2.6.1.4: Two values (other than NaNs) with the same object
representation compare equal, but values that compare equal may have
different object representations.

In 7.12.13, the fmax and fmin functions treat NaNs as missing
arguments. Most other operations return NaN if an argument is NaN, or
for a domain error.

7.12.14 specifies comparison macros that are quiet versions of the
relational operators.

BTW floating-point exceptions in C and IEEE are not the same as
exceptions in higher level languages. The behavior of signalling NaNs
are not defined in C. Only quiet NaNs are returned from operations.
An invalid floating-point exception may well just set a status flag.
That may be tested after a set of calculations. With pipelining the
exact cause of the exception will be unknown.
--
Pete Forman -./\.- Disclaimer: This post is originated
WesternGeco -./\.- by myself and does not represent
pe*********@westerngeco.com -./\.- the opinion of Schlumberger or
http://petef.port5.com -./\.- WesternGeco.

[Marc 'BlackJack' Rintsch]

On Fri, 25 Jan 2008 07:57:38 +0000, Pete Forman wrote:

Mark Dickinson <di******@gmail.comwrites:

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 any more.

There are separate Python operators, "==" and "is".

So what? ``==`` is used for both ``==`` and set/dict/list membership
testing and "nested comparison" of those structures. There is no ``is``
involved.

Ciao,
Marc 'BlackJack' Rintsch

[Mark Dickinson]

On Jan 28, 6:50 am, Antoon Pardon <[e-mail]:

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 work with inf, and
NaN results, would get silent NaN where no exceptions would be thrown.

I also think this would be the ideal situation. Getting there would
require a lot of thought, planning, a PEP or two, and some hard work
and tricky coding to deal with all the different ways that the C
compiler, libm and hardware might try to mess things up. Right now
I don't have time for this :-( Anyone else?

Putting aside sorting and max/min, what is the use-case for having
comparisons with NaN succeed? What benefit will it give you?

I guess the same benefit it gives to those that have operations with
NaN succeed. If 3 * NaN should succeed and all sort of other stuff,
why suddenly make an exception for 3 < NaN.

Right. This is especially true when the result of the comparison is
treated as number (i.e. 0 or 1) rather than as a boolean,
and goes back into the calculation in some way. On the other hand,
there are certainly situations where you want a comparison with a
NaN to raise an exception. I guess this is why IEEE-754r provides
two sets of comparison operators: signaling and non-signaling.

Mark

[Mark Dickinson]

On Jan 28, 6:50 am, Antoon Pardon <[e-mail]:

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 the form of the Decimal type. This does
exactly what you suggest: by default, users get Python exceptions
instead of NaNs and/or infinities, but the user can override the
defaults to switch off the various traps (Overflow, Invalid, etc.) and
work directly with NaNs and infinities if (s)he prefers.

Note also that decimal.py runs to over 5000 lines of (Python) code!
And that's without having to deal with the vagaries of the C-compiler/
library/OS/hardware, since everything's implemented directly in
Python. A surprisingly small amount of that code is actually 'real'
mathematics: most of it is devoted to dealing correctly with
infinities, NaNs, signed zeros, subnormals, `ideal' exponents, traps,
flags, etc.

Mark