From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id PAA12427; Mon, 20 Oct 2003 15:43:13 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id PAA07447 for ; Mon, 20 Oct 2003 15:43:12 +0200 (MET DST) Received: from mclean.mail.mindspring.net (mclean.mail.mindspring.net [207.69.200.57]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h9KDhB125446; Mon, 20 Oct 2003 15:43:11 +0200 (MET DST) Received: from user-0ccekej.cable.mindspring.com ([24.199.81.211] helo=minsky-primus.homeip.net) by mclean.mail.mindspring.net with smtp (Exim 3.33 #1) id 1ABaJS-0002Kv-00; Mon, 20 Oct 2003 09:43:10 -0400 Received: from 141.155.88.179 (SquirrelMail authenticated user yminsky) by minsky-primus.homeip.net with HTTP; Mon, 20 Oct 2003 09:43:10 -0400 (EDT) Message-ID: <19541.141.155.88.179.1066657390.squirrel@minsky-primus.homeip.net> In-Reply-To: <20031020152914.C13138@pauillac.inria.fr> References: <51792.141.155.88.179.1066142234.squirrel@minsky-primus.homeip.net> <20031016151658.A5633@pauillac.inria.fr> <1066402553.4570.65.camel@pelican> <1066434942.2933.70.camel@dragonfly.localdomain> <20031020152914.C13138@pauillac.inria.fr> Date: Mon, 20 Oct 2003 09:43:10 -0400 (EDT) Subject: Re: [Caml-list] Weird behavior with nan's and min/max From: "Yaron Minsky" To: "Xavier Leroy" Cc: "Caml List" User-Agent: SquirrelMail/1.4.2-1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 yaron:01 minsky:01 yminsky:01 cornell:01 pervasive:01 weirdness:01 equality:01 polymorphic:01 polymorphic:01 float:02 float:02 precisely:02 exception:02 comparison:02 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk >> > Doesn't the polymorphic comparison have to be a total order? > > Pervasive.compare must be a total order, so it would need to throw an > exception if its arguments are unordered (e.g. one is "nan"). > The other comparisons (=, <, etc) could implement a partial order, > returning "false" in the "unordered" case (except for <>, which should > return "true" in this case). OK, so this makes me feel a little better -- turns out the polymorphic compare is a total order. There is some remaining weirdness though (as one would expect), in that the polymorphic nan is equal to everything else. As a strange result, if you create a Set from the polymorphic compare, you get the following weird result: # Set.elements (Set.of_list [Some 3.; Some nan]);; - : float option list = [Some 3.] # Set.elements (Set.of_list [Some nan; Some 3.]);; - : float option list = [Some nan] I suppose it's too late to change this kind of behavior, but wouldn't it make more sense for nan to be different from everything but itself? Maybe make nan the smallest thing bigger than -infinitiy, or the largest thing smaller than infinity? It's not perfect, but it seems better than making it equal to everything. By the way, in my context, there are plenty of times where it makes sense to have sets and maps of things that contain floating point numbers (although rarely of floating point numbers proper.) In practice, I rely on equality holding only when two floating point numbers were derived in precisely the same way or were copies of each other. But it does come up quite a bit. y y ------------------- 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