









 
 




 
 


I ran into one of those things.
Again.
take a look at:
#for (T, 0, 100, 0.1)
#debug concat (str(T, 3, 16), "\n")
#end
Around the 13th decimal place there starts to be some > N.0 behaviour which
throws off looking for the regular integer occurrences with mod (N, 1)
I'm curious why it's not in actual even steps of N.10000000000000000000.... out
to however many places POVRay numbers go.
Post a reply to this message


 
 




 
 


Am 03.08.2018 um 01:15 schrieb Bald Eagle:
> I ran into one of those things.
> Again.
>
> take a look at:
>
> #for (T, 0, 100, 0.1)
> #debug concat (str(T, 3, 16), "\n")
> #end
>
> Around the 13th decimal place there starts to be some > N.0 behaviour which
> throws off looking for the regular integer occurrences with mod (N, 1)
>
> I'm curious why it's not in actual even steps of N.10000000000000000000.... out
> to however many places POVRay numbers go.
This is a fundamental problem in floatingpoint arithmetic  both in
computers and on paper.
As an example, take the rational number 1/3 represented as a decimal
number with, say, 5 significant digits. If you compute 3*(1/3) by adding
1/3 to itself three times, you get:
0.33333
+ 0.33333
+ 0.33333

= 0.99999
As you can see, the result doesn't quite add up to 1.00000.
The problem always arises when you try to represent a rational number
R=N/M as a finitedigits floatingpoint number in base B, and the
denominator M of the fraction has at least one prime factor that isn't
also a prime factor of the base B.
In the binary system typically used in computers, this imples that the
problem arises whenever M is not a power of 2.
Note that 0.1 represents a /decimal fraction/, namely 1/10. Since 10 has
5 as one of its prime factors, which isn't a power of 2, the problem
applies here.
In for loops, the problem can be avoided altogether by always using an
integer loop variable, and from that "technical" loop variable compute
an "effective" loop variable via multiplication or division, e.g.:
#for (I, 0, 1000, 1)
#local T = I * 0.1;
....
#end
Post a reply to this message


 
 




 
 


clipka <ano### [at] anonymousorg> wrote:
> In the binary system typically used in computers, this imples that the
> problem arises whenever M is not a power of 2.
So, POVRay reinforces the patriarchal stranglehold that the Old Boy's Club has
on implementing a nonbinary system, eh?
> Note that 0.1 represents a /decimal fraction/, namely 1/10. Since 10 has
> 5 as one of its prime factors, which isn't a power of 2, the problem
> applies here.
I thought it was something like that  just wanted to be sure.
> In for loops, the problem can be avoided altogether by always using an
> integer loop variable, and from that "technical" loop variable compute
> an "effective" loop variable via multiplication or division, e.g.:
>
> #for (I, 0, 1000, 1)
> #local T = I * 0.1;
> ....
> #end
Well, this is interesting:
(a) it works  thanks! :)
(b) my #debug output still shows a "remainder" in the 14th or 15th decimal place
 is that just an artifact showing up _after_ mod() is made happy?
Post a reply to this message


 
 




 
 


Le 180803 Ã 08:33, Bald Eagle a Ã©critÂ :
> clipka <ano### [at] anonymousorg> wrote:
>
>
>> In the binary system typically used in computers, this imples that the
>> problem arises whenever M is not a power of 2.
>
> So, POVRay reinforces the patriarchal stranglehold that the Old Boy's Club has
> on implementing a nonbinary system, eh?
>
>> Note that 0.1 represents a /decimal fraction/, namely 1/10. Since 10 has
>> 5 as one of its prime factors, which isn't a power of 2, the problem
>> applies here.
>
>
> I thought it was something like that  just wanted to be sure.
>
>
>> In for loops, the problem can be avoided altogether by always using an
>> integer loop variable, and from that "technical" loop variable compute
>> an "effective" loop variable via multiplication or division, e.g.:
>>
>> #for (I, 0, 1000, 1)
>> #local T = I * 0.1;
>> ....
>> #end
>
> Well, this is interesting:
> (a) it works  thanks! :)
>
> (b) my #debug output still shows a "remainder" in the 14th or 15th decimal place
>  is that just an artifact showing up _after_ mod() is made happy?
>
>
>
An error at the 14+th decimal place can be expected due to the limits of
the FP processor. It only have a finite mantissa length.
You'd need a triple or quadruple precision capable floating point unit.
Post a reply to this message


 
 




 

