caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Xavier Leroy <xavier.leroy@inria.fr>
To: Yaron Minsky <yminsky@cs.cornell.edu>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Weird behavior with nan's and min/max
Date: Thu, 16 Oct 2003 15:16:58 +0200	[thread overview]
Message-ID: <20031016151658.A5633@pauillac.inria.fr> (raw)
In-Reply-To: <51792.141.155.88.179.1066142234.squirrel@minsky-primus.homeip.net>; from yminsky@cs.cornell.edu on Tue, Oct 14, 2003 at 10:37:14AM -0400

> Now here's the weird bit.  I decided I wanted a polymorphic comparison
> that wouldn't have this problem.  But this is a little harder than it
> seems, since it turns out that specialized float version of equality is
> different from the polymorphic version.

Yes, it's a long-standing bug for which we haven't yet a good
solution.  More exactly, there are two problematic solutions:

1- Fix polymorphic equality so that it behaves like IEEE equality on floats,
i.e. it always returns false when one of its arguments is NaN.
The problem is that this breaks the implication
        x == y  imply  x = y
and thus the current implementation of polymorphic equality needs to
be made less efficient.  Currently, x = y starts by testing x == y
and returns true if the pointer equality holds.  But this could be the
wrong result according to the new specification, since x can contain
an NaN somewhere.  Hence, polymorphic equality would have to traverse
its two arguments even when they are physically the same.  The
performance impact of this change on real programs is unknown.

2- As J M Skaller proposed, change the behavior of polymorphic
equality and its version specialized to floats so that nan = nan
and nan <> x if x <> nan.  Similar changes need to be done on the
<>, <= and >= tests for consistency.  IEEE comparisons would then have to be
provided as separate primitives.  This preserves the implication
x == y ==> x = y.  But the machine code generated for =, <>, <= and >=
over floats will have to be a lot less efficient than it is now, since
all processors implement float comparisons as per IEEE.

Coming back to your proposed workaround:

> # let raw_min = min
> val raw_min : 'a -> 'a -> 'a = <fun>
> # let min x y =
>   if not (y = y) then y
>   else if not (x = x) then x
>   else raw_min x y
> ;;

A way to make this work would be to replace the "not (x = x)" tests
by calls to the following function (of type 'a -> bool):

let is_obj_nan x =
  Obj.tag (Obj.repr x) = Obj.double_tag &&
  (let f = (Obj.magic x : float) in not (f = f))

Not pretty, I agree.

- Xavier Leroy

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners


  parent reply	other threads:[~2003-10-16 13:17 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-14 14:37 Yaron Minsky
2003-10-14 14:56 ` Yaron Minsky
2003-10-14 20:52   ` Yaron Minsky
2003-10-14 23:43     ` skaller
2003-10-16 17:29       ` Hendrik Tews
2003-10-16 13:16 ` Xavier Leroy [this message]
2003-10-16 14:01   ` Yaron Minsky
2003-10-17  9:26     ` [Caml-list] Test nan (was: Weird behavior with nan's and min/max) Christophe TROESTLER
2003-10-16 21:40   ` [Caml-list] Weird behavior with nan's and min/max Yaron Minsky
2003-10-16 21:50     ` Yaron Minsky
2003-10-16 22:52     ` Damien Doligez
2003-10-17 14:55   ` skaller
2003-10-17 15:14     ` Floating point exceptions (Was Re: [Caml-list] Weird behavior with nan's and min/max) Yaron Minsky
2003-10-17 23:55     ` [Caml-list] Weird behavior with nan's and min/max Yaron M. Minsky
2003-10-20 13:29       ` Xavier Leroy
2003-10-20 13:43         ` Yaron Minsky
2003-10-20 14:24           ` Xavier Leroy
2003-10-16 23:55 ` [Caml-list] " Jed Davis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20031016151658.A5633@pauillac.inria.fr \
    --to=xavier.leroy@inria.fr \
    --cc=caml-list@inria.fr \
    --cc=yminsky@cs.cornell.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).