POV-Ray : Newsgroups : povray.beta-test : initial_clock / final_clock behaviour : Re: initial_clock / final_clock behaviour Server Time
30 Jul 2024 00:20:50 EDT (-0400)
  Re: initial_clock / final_clock behaviour  
From: Thorsten Froehlich
Date: 26 Mar 2002 16:17:20
Message: <3ca0e560@news.povray.org>
In article <3ca0dba3@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

> However, I still stand by my belief that a supposedly constant value such as
> initial_clock should not even variate the slightest bit from frame to frame.

Try to see it this way:  Specify a value to to the 20th digit on the command
line and then look at what you get when displaying it.  You will notice some
variation (unless you select certain values that will always be precise).  Of
course this variation will not be from frame to frame, but it still exists.
in fact, by carefully tweaking the values in the INI file it is possible to
get *closer* or even match the value you specified using the calculation
method compared to the internally known initial_clock.

This is because the precision is _finite_ but _very_ complex to track when
using floating-point numbers, and the only correct way to handle this is to
not depend on infinite precision at all, ever.  For this reason POV-Ray
internally has its EPSILON at 10e-10 by default because most platforms cannot
provide more accurate results even after just a "few" calculations.  This is
also the reason why the equality comparison operators take EPSILON into
account in POV-Ray.

Sure, you can display the value such that the precision error is visible, but
then again you can probably display 40 digits in many cases and 30 of them
will just be "random" jitter...

    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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.