|
|
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
|
|