« Return to Thread: strange behaviour of compare/3

Re: strange behaviour of compare/3

by Richard O'Keefe :: Rate this Message:

Reply to Author | View in Thread


On 15 Jun 2009, at 3:05 pm, Ulrich Neumerkel wrote:
> Is it only the mixing of integers and floats that is problematic?  If
> so, a floatcompare/3 nd intcompare/3 might make sense?

Floats are the problem.
There there is something especially dubious about comparing
exact numbers (integers in this case) with inexact ones.

The heart of the problem here is that the original poster
knew that 1 =:= 1.0 (they are numerically) equal
and therefore expected them to be compared = using compare/3.

>
> Aren't floats in general not the best candidates for compare/3,
> as equality is problematic?

TERM-equality is not problematic at all.  Two terms are identical
(==) if and only if they are indistinguishable.  Term ordering is
not problematic except for NaNs:
  -infinity @< -finite @< -0.0 @< +0.0 @< +finite @< +infinity
As for NaNs, it doesn't really matter where term ordering puts
them as long as it is consistent.

I say that term ordering is not problematic.
It isn't.  What _is_ problematic (thank you, IEEE 754 committee)
is expecting _any_ total order on floats to match up with < =:= and >.
We MUST distinguish -0.0 \== 0.0 because they are distinguishable
in several IEEE-conformant ways.  But we must ALSO have -0.0 =:= 0.0.

Sorting floats in C is a pain, because you always have to take care
to segregate the NaNs first.  In fact, when sorting floats in C, I
do a first pass to segregate
  - numbers with negative sign, including -0.0
  - numbers with positive sign, including +0.0
  - NaNs
and then I sort the first two halves separately.

_______________________________________________
SWI-Prolog mailing list
SWI-Prolog@...
https://mailbox.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog

 « Return to Thread: strange behaviour of compare/3