In article <3ca0688b@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

> #declare Value1 = (Initial_Clock1-0.5)*100000;

After looking closer at what you are doing (multiplication by 100000  to see
more digits right of the comma) and your precision arguments and way of
testing it, I conclude you are probably misunderstanding the meaning of
"precision of floating-point numbers".

See, what you are effectively doing is tricking the display to show 19 digits.

I guess you assume "precision" refer to the part right of the comma.  However,
this is _not_ how floating-point precision is defined!

Floating-point numbers are not you every day binary (or decimal for that
matter) numbers.  I am not sure you are aware, but in memory double precision
(IEEE754 standard) floating-point numbers have exactly 64-bits to store your
number.  64 bits allow exactly 2^64 possible numbers to be represented.  This
implies about 1.845*10^19 possible numbers, which makes it obvious that more
than 19 digits of a number (which is not one of these 1.845*10^19 numbers that
can be represented as exact values) are impossible to be represented no matter
how you calculate it.  In order to allow very small values down to 2*10^-308
and very big values up to 2*10^+308 floating-point numbers use an exponent-
based format (there are many books about, so I am not going to explain it
here).  Effectively you get only about 15 to 16 digits precision after a few
calculations, and a steady decrease of precision when applying more and more
calculations.

So, what you are displaying in your example is in fact exceeding (!!!) the
available precision that is mathematically possible at some point.  I hope
this explains a bit better why you cannot expect never changing values - they
will nearly always change in a not mathematically exact way after applying
even a single operation to them.  thus, requiring a value to be always
constant is only possible if you never use it, because as soon as you do you
likely will perform some calculation and thus create similar inaccuracies
sooner or later.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message