Thorsten Froehlich <tho### [at] trfde> wrote:
> On 27.06.11 08:14, Warp wrote:
> >    The difference is subtle, but exists.

> Yes, at that point there will also be a difference in the computation. It 
> will be noticeable above 10 million frames (10**7), which is 46 hours for a 
> 60 fps animation. This is due to the clock value being transmitted as 32-bit 
> float while the computation is done with 64-bit floats. Thus, to see the 
> error, you need to exceed the precision limit of the 64-bit float, which is 
> about eight decimal digits greater than that of a 32-bit float.

  Nope. All you need to do to get a noticeable rounding error is to see
if the clock value in the final frame is 1.0.

  Is not using the more accurate method a matter of principle or something?

-- 
                                                          - Warp

Post a reply to this message

On 29.06.11 21:59, Warp wrote:
> Thorsten Froehlich<tho### [at] trfde>  wrote:
>> On 27.06.11 08:14, Warp wrote:
>>>     The difference is subtle, but exists.
>
>> Yes, at that point there will also be a difference in the computation. It
>> will be noticeable above 10 million frames (10**7), which is 46 hours for a
>> 60 fps animation. This is due to the clock value being transmitted as 32-bit
>> float while the computation is done with 64-bit floats. Thus, to see the
>> error, you need to exceed the precision limit of the 64-bit float, which is
>> about eight decimal digits greater than that of a 32-bit float.
>
>    Nope. All you need to do to get a noticeable rounding error is to see
> if the clock value in the final frame is 1.0.

??? As I said, you will see that error above roughly 10**7 frames.

	Thorsten

Post a reply to this message