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 QAA16844; Mon, 20 Oct 2003 16:24:47 +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 QAA31481 for ; Mon, 20 Oct 2003 16:24:46 +0200 (MET DST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h9KEOd100034; Mon, 20 Oct 2003 16:24:39 +0200 (MET DST) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id QAA15606; Mon, 20 Oct 2003 16:24:39 +0200 (MET DST) Date: Mon, 20 Oct 2003 16:24:38 +0200 From: Xavier Leroy To: Yaron Minsky Cc: Caml List Subject: Re: [Caml-list] Weird behavior with nan's and min/max Message-ID: <20031020162438.A19276@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> <19541.141.155.88.179.1066657390.squirrel@minsky-primus.homeip.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <19541.141.155.88.179.1066657390.squirrel@minsky-primus.homeip.net>; from yminsky@cs.cornell.edu on Mon, Oct 20, 2003 at 09:43:10AM -0400 X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 pervasive:01 behave:01 weirdness:01 polymorphic:01 polymorphic:01 exception:02 clearer:02 behavior:03 behavior:03 suppose:03 partial:03 rarely:03 arguments:03 nan:04 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > > 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. I should have been clearer: "would need to..." implies that the current implementation doesn't do this; only the alternate implementations that I suggested in a previous message could (and should) behave this way. > There is some remaining weirdness though (as > one would expect), in that the polymorphic nan is equal to everything > else. Again, it's a problem (the problem?) with the current implementation, and it needs fixing. > 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? Yes, that would be much better. According to IEEE, nan should even be different from itself... > Maybe make nan the smallest thing bigger than -infinitiy, or the > largest thing smaller than infinity? This isn't what IEEE does. > 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.) I'd be interested in some examples, but we can continue this discussion off the list. - 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