Velocity Reviews > When is min(a, b) != min(b, a)?

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

Albert Hopkins
Guest
Posts: n/a

 01-21-2008
This issue may have been referred to in
news:<(E-Mail Removed)> 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 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
Guest
Posts: n/a

 01-21-2008
'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:<(E-Mail Removed)> 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 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
Guest
Posts: n/a

 01-21-2008
'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')

Guest
Posts: n/a

 01-21-2008
On Jan 21, 3:15 am, Albert Hopkins <(E-Mail Removed)> wrote:
> This issue may have been referred to in
> <news:(E-Mail Removed)> 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 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?

Albert Hopkins
Guest
Posts: n/a

 01-21-2008
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

Steven D'Aprano
Guest
Posts: n/a

 01-21-2008
On Sun, 20 Jan 2008 21:15:02 -0600, Albert Hopkins wrote:

> This issue may have been referred to in
> news:<(E-Mail Removed)> 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 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).

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". Comparisons with NaNs are unordered, and
so expressions like "x < nan" should signal an exception.

(However both == and != do not signal exceptions, they return False and
True respectively.)

Unfortunately, the standard conflicts with Python's requirement that
comparisons should always return True or False, so the next "least bad"
alternative is to have comparisons with NaN to return False. That is:

>>> 5 < float('nan')

False
>>> 5 >= float('nan')

False

So BEWARE of assuming that if x < y returns False, y >= x must return
True. That does not hold for floats.

Aside: Apple's Power PC Numerics math library extended the usual six
comparison operators to fourteen. I don't judge whether this was a good
idea or not.

http://developer.apple.com/documenta...tml#MARKER-9-1

Given that NaNs are unordered, the "right" thing for max() and min() to
do is raise an exception. But failing that, the next best thing would be
for them to ignore any NaNs. Any way you look at it, for min or max to
return a nan is a mistake. Possibly even a bug.

> 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 ?

Presently, you can't rely on *any* behaviour of NaNs and INFs in Python,
since they all depend on the underlying C library. Even whether or not
you can create them is not defined in Python.

--
Steven

Jason
Guest
Posts: n/a

 01-21-2008
On Jan 21, 12:00 am, Albert Hopkins <(E-Mail Removed)> 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 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
Guest
Posts: n/a

 01-21-2008
On Jan 21, 9:55*am, Jason <(E-Mail Removed)> 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 "1.#QNAN".

I believe this will be fixed in Python 2.6

Mark

Grant Edwards
Guest
Posts: n/a

 01-21-2008
On 2008-01-21, Albert Hopkins <(E-Mail Removed)> wrote:
> This issue may have been referred to in
> news:<(E-Mail Removed)> 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 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).

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.

> 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 ?

According to Wikipedia:

In the proposed IEEE 754r revision of that standard the same
rule applies, except that a few anomalous functions (such as
the maxnum function, which returns the maximum of two
operands which are expected to be numbers) favour numbers --
if just one of the operands is a NaN then the value of the
other operand is returned.

A different approach has been implemented in the NaN
'toolbox' for GNU Octave and MATLAB. In that toolbox, NaNs
are assumed to represent missing values and so the
statistical functions ignore NaNs in the data instead of
propagating them. Every computation in the NaN toolbox is
based on the data values only, which can be useful if it is
known that NaNs cannot be produced by errors.

--
Grant Edwards grante Yow! Remember, in 2039,
at MOUSSE & PASTA will
visi.com be available ONLY by
prescription!!

Grant Edwards
Guest
Posts: n/a

 01-21-2008
On 2008-01-21, Jason <(E-Mail Removed)> 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 far more complicated than would using them.

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