Le 16/12/2013 19:03, clipka nous fit lire :
> Am 16.12.2013 14:26, schrieb David Given:
> 
>> I run into the opposite problem; I render astronomical objects, and
>> routinely run afoul of the maximum draw limit fudge factor where objects
>> that are a long way away are ignored completely. (My moon pictures, for
>> example, have to have the sun artifically close or it doesn't show up.)
>>
>> What's this limit actually for? I can see that the lower limit has some
>> utility in order to cope sanely with rounding errors, but I can't think
>> of any reason for an upper limit.
> 
> I guess the true reason for the existence of all these limits has been
> lost in the mists of time.
> 
> My theory is that the developers back then were not too familiar with
> the numeric limits of the IEEE floating point formats, nor with rounding
> error estimation & handling.
> 
And a time where floating point could be 32 bits... and portability
meant lowest common denominator. (and Ieee-754 was not that common).

Also keep in mind that some solver need squared value, or even a cube,
so 2e+31 (biggest single precision value on 32 bits) introduce a limit
of 1e+15 or 1e+10 if you do not want the square/cube to go through the roof.

The minimal delta that can be stored around 1 is of the order of 1e-7.

With 64 bits floating point value now everywhere, there is less impact
on the top limit (the max is at above 1e+308, so a cube would have issue
after 1e+100), yet the precision only got 30 more bits, that's only
2^30, or 10^9. so 1e-7 should not go further than 1e-16
(and if a square/root is in the process, the 1e-7 became 1e-3 where
1e-16 become a lame 1e-8 or 1e-7)

(I talked of square and cube, but that's also true for any product of 2
or 3 terms)

Post a reply to this message