Thorsten Froehlich <tho### [at] trfde> wrote:

> In article <3a9690a0@news.povray.org> , Geoff Wedig 
> <wed### [at] darwinepbicwruedu>  wrote:

>> Except for the slight problem that floats can represent integers

> The problem is not that they can't represent integers if rounded at for
> example the tenth digit, but if you take the whole floating-point number
> you may well have a case like this (the error is just a _very_ simple
> example, the real error will be more complicated and may appear in
> different operations because of the way floating-point numbers are
> represented internally).

> Imagine:   integer 4 = floating-point 4.00000000001
>            integer 2 = floating-point 2.0000000001

> 2.00000000001 + 2.00000000001 = 4.00000000002 != 4.00000000001

> Get the idea?

I deal with float and integer problems every day.  My work is in
mathematical computation, so yeah, I've heard of the idea.

And it's completely irrelevant.  It may be true in many cases, but in *this*
case, we're dealing with a float that was *initialized* to an integer, and
with integral values small enough to fit in the storage bits, they're stored
as integers (basically).  It's only when you have to use the shift bits that
funky things happen.  This has *long* been a standard.  If I were doing
dividing, where a small roundoff could have occured, then there might've
been some question, but in this case, we're dealing with integers added to
integers, albeit stored as floats.  I can't see why they'd conflict in this
fashion.  Or is POV doing something extremely funky with the clock?  I
suppose it's possible that rather than use the settings I gave it for
initial and final clock, it still does 0-1, but then multiplies it by the
difference and adds the initial_clock, to get the clock setting given to the
scene file, but that seems like a lot of work when the true values are right
there.

Geoff

Post a reply to this message