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 WAA24234; Fri, 2 Apr 2004 22:53:26 +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 WAA24120 for ; Fri, 2 Apr 2004 22:53:25 +0200 (MET DST) Received: from herd.plethora.net (herd.plethora.net [205.166.146.1]) by nez-perce.inria.fr (8.12.10/8.12.10) with ESMTP id i32KsAjq001801 for ; Fri, 2 Apr 2004 22:54:11 +0200 Received: from bhurt.plethora.net (bhurt.plethora.net [205.166.146.49]) by herd.plethora.net (8.11.6/8.10.1) with ESMTP id i32KrEQ08087; Fri, 2 Apr 2004 14:53:18 -0600 (CST) Date: Fri, 2 Apr 2004 15:58:59 -0600 (CST) From: Brian Hurt X-X-Sender: bhurt@localhost.localdomain To: Zeno Lee , Ocaml Mailing List Subject: Re: [Caml-list] weird floating poing behavior on windows In-Reply-To: <008101c418ea$3ff43780$6401a8c0@xp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Miltered: at nez-perce by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 zeno:01 binary:02 worse:03 wrote:03 behavior:03 algorithms:03 redirect:95 3.0,:04 cancel:94 decimal:05 decimal:05 numerical:05 lee:94 brian:06 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk X-Status: X-Keywords: X-UID: 40 On Fri, 2 Apr 2004, Zeno Lee wrote: > Can anyone tell me what's going on here? Is this a known issue on windows? This is a known issue with floating point numbers. Take a class or get a book on numerical analysis is my recommendation. Here's the basic problem: let's assume our machine works in base 10 instead of base 2, and that floating point numbers only hold 4 decimal digits. So how does the machine represent 1.0/3.0? It can't, not exactly. It's instead represented as 0.3333. Four digits of accuracy, remember? So we take this number, and multiply it by 3.0, we get not the expected answer of 1.0, but instead 0.3333*3, or 0.9999. Opps. Now, in finite precision binary fp, we can't exactly represent 1/5th, just like we can't exactly represent 1/3 in finite precision decimal. The system gets "close", but can't do it exactly, so every once in a while you get an answer a little larger or smaller than expected. Even worse, these small errors can accumulate, snowballing into huge errors. A lot of very intelligent people spend years making algorithms in which these errors tend to cancel each other out instead of accumulating- so that if this calculation comes out a little high, the next calculation will likely come out a little low. You can get a PhD and spend your life doing this, and a lot of people have. My recommendation is to simply get a book, and do things the way they tell you to. -- "Usenet is like a herd of performing elephants with diarrhea -- massive, difficult to redirect, awe-inspiring, entertaining, and a source of mind-boggling amounts of excrement when you least expect it." - Gene Spafford Brian ------------------- 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