From chemistry-request # - at - # server.ccl.net Wed Jul 5 23:51:51 2000 Received: from alanina.df.ibilce.unesp.br (alanina.df.ibilce.unesp.br [200.145.203.25]) by server.ccl.net (8.8.7/8.8.7) with ESMTP id XAA02813 for ; Wed, 5 Jul 2000 23:51:50 -0400 Received: from localhost (irbis*- at -*localhost) by alanina.df.ibilce.unesp.br (8.10.1/8.9.3) with ESMTP id e660xC431957; Wed, 5 Jul 2000 21:59:12 -0300 X-Authentication-Warning: alanina.df.ibilce.unesp.br: irbis owned process doing -bs Date: Wed, 5 Jul 2000 21:59:12 -0300 (BRT) From: David Santo Orcero X-Sender: irbis #at# alanina To: Iraj Daizadeh cc: chemistry -x- at -x- ccl.net Subject: Re: CCL:comutational precision: removing round-off errors. In-Reply-To: <39636FA4.CF35D7C0 "-at-" genxy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello! > If one takes 625 and divides this number by, lets say, 5 on a computer > one may get one of > two numbers that look like: 125.000000000000000001 and > 124.4999999999999999 . > > Is this true? and, if so, how does one remove possible rounding errors Yes, it is true. And there is no solution, sorry. Here is why: Numbers in floating point format are something like: Number= (-1)^sign * (1.mantisa) * base ^ (exponent - kexp) Mantisa can be in other format, but uses to be as (1.mantisa); after a calculus, the number is LRed to its first digit is 1 (on binary format). Thus, that 1 doesn't need to be almacenated on the memory of the computer. This is called "normalized floating point". Nearly all computers uses this. Base uses to be 2; kexp, as far as I renember, 127 in IEEE754 32 bits and 1023 in IEEE754 64bits. 0 is not representable. For this, it is used a special kind of representation, that allows representate +Inf, -Inf and NaN. It allows also +0 and -0, but this is another story... Then, you will have a number representated as: (sign, mantisa, exponent) As you see, not all numbers are exactly representated. Some numbers that are simple on decimal representation, on floating point would need infinite precision. The propagation of the error by the non-exact nature of floating point numbers is really complex, and for really short integration steps can be 1 or 2 order of magnitude higher that the error for the truncation of the Taylor's serie by the integration algorithm. Sorry for my bad english. Sorry also by the bad news. ;-) I hope that this message helps. Yours: David