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 WAA09612; Tue, 14 Oct 2003 22:52:17 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id WAA23895 for ; Tue, 14 Oct 2003 22:52:16 +0200 (MET DST) Received: from hall.mail.mindspring.net (hall.mail.mindspring.net [207.69.200.60]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id h9EKqF119701 for ; Tue, 14 Oct 2003 22:52:15 +0200 (MET DST) Received: from user-0ccekej.cable.mindspring.com ([24.199.81.211] helo=minsky-primus.homeip.net) by hall.mail.mindspring.net with smtp (Exim 3.33 #1) id 1A9W9O-0007Ce-00 for caml-list@inria.fr; Tue, 14 Oct 2003 16:52:14 -0400 Received: from 141.155.88.179 (SquirrelMail authenticated user yminsky) by minsky-primus.homeip.net with HTTP; Tue, 14 Oct 2003 16:52:14 -0400 (EDT) Message-ID: <63219.141.155.88.179.1066164734.squirrel@minsky-primus.homeip.net> In-Reply-To: <54490.141.155.88.179.1066143413.squirrel@minsky-primus.homeip.net> References: <51792.141.155.88.179.1066142234.squirrel@minsky-primus.homeip.net> <54490.141.155.88.179.1066143413.squirrel@minsky-primus.homeip.net> Date: Tue, 14 Oct 2003 16:52:14 -0400 (EDT) Subject: Re: [Caml-list] Weird behavior with nan's and min/max From: "Yaron Minsky" To: caml-list@inria.fr 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 misses:01 compile-time:01 floats:01 weirdness:01 floats:01 semantics:01 evaluates:01 evaluates:01 equality:01 polymorphic:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk I've gotten a bunch of replies on this, some pointing out that the proper result could be achieved with various methods for detecting nan's explicitly. This kind of misses my point, which is that this leads to some pretty serious violations of the principle of least surprise. The first is that adding a type annotation to a function can change its semantics: the specialized min function I came up with works substantively differently depending on whether it's known at compile-time that it operates only on floats. The second weirdness is the breaking of (==) => (=), since "nan == nan" evaluates to true and "nan = nan" evaluates to false. These are pretty weird and unpleasant surprises, and now that I've been bitten by them I'm eager to avoid them in the future. Hence my desire for a polymorphic equality function that doesn't change it's behavior when applied to floats. 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