Hello,

when I was testing how I can translate a float like

1.23456789e-28

into a 6 bytes notation for a ppm file I noticed that
the float function int() has a maximum value.
Try this:

*************************************
#declare Num1 = pow(2,30);
#declare Num2 = pow(2,31);
#declare Num3 = pow(2,32);
#declare Int1 = int(Num1);
#declare Int2 = int(Num2);
#declare Int3 = int(Num3);
#debug concat("\nNum1 = ",str(Num1,0,-1),
       " | Num2 = ",str(Num2,0,-1),
       " | Num3 = ",str(Num1,0,-1))
#debug concat("\nInt1 = ",str(Int1,0,-1),
       " | Int2 = ",str(Int2,0,-1),
       " | Int3 = ",str(Int3,0,-1),"\n")
*************************************
The result for me was:

Persistence of Vision(tm) Ray Tracer Version 3.5 win32 (.icl)
....
Num1 = 1073741824.000000 | Num2 = 2147483648.000000 | Num3 = 1073741824.000000
Int1 = 1073741824.000000 | Int2 = -2147483648.000000 | Int3 = -2147483648.000000

There is no warning about a max value in the manual.
Maybe it is wise to do this.

Jaap Frank

Post a reply to this message

Seemingly POV-Ray does an "(int)(x)" operation, when it should instead
make a "floor(x)".

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

In article <3ec181ad@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   Seemingly POV-Ray does an "(int)(x)" operation, when it should instead
> make a "floor(x)".

Not floor(), the int() operation is a bit different, which is why POV 
has both floor() and int() functions. floor() rounds to the next lower 
integer, but int() truncates the fractional part, effectively rounding 
towards 0. The standard C rint() function may be a better way to 
implement this.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Christopher James Huff <cja### [at] earthlinknet> wrote:
> The standard C rint() function may be a better way to 
> implement this.

  Rounding would change its behaviour, which might not be good (eg. int(0.6)
would now give 1 instead of 0).

  If the different behaviour of floor() with regard to negative values is
a problem, then the solution is easy: x<0 ? -floor(-x) : floor(x)

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

This snippet also shows what is happening, perhaps more clearly:

#declare r = pow(2,31) - 3;
#declare i = int(r);
#while (i>0)
   #declare r = r + 1;
   #declare i = int(r);
   #debug concat("r = ", str(r,0,-1), ";  int(r) = ", str(i,0,-1), "\n")
#end

This produces the following three lines in the Messages pane (with POV-Ray
3.5 on WinXP):

r = 2147483646.000000;  int(r) = 2147483646.000000
r = 2147483647.000000;  int(r) = 2147483647.000000
r = 2147483648.000000;  int(r) = -2147483648.000000

So, this demonstrates this implementation of POV represents integers with a
32 bit number wheel, that wraps from positive to negative values at 2 raised
to the 31st power (2^31, 2**31, or pow(2,31). This is of course because the
high order bit is used as a sign bit.

Suggestions:

Anyone working with large numbers should be made aware that POV maps all
real numbers to this number wheel when the int( ) function is used;

This awareness could be made available by modifying the entry for the int( )
function in the POV manual;

It would be nice to suggest a good alternative for persons whose work is
affected by this. It would be helpful if this was also included in the
manual.

An alternative that should work in all cases is

// given an original float f of unknown magnitude that might exceed the
limits of the int( ) function
#declare tmp = floor ( abs( f ) );
#declare f = ( f > 0 ? tmp : -tmp);

(Above is untested; beware possible typos, etc, and perhaps others should
check my logic)


--
Will Woodhull
Thornhenge, SW Oregon, USA
willl.at.thornhenge.net


PS-- it should be noted that the size of the number wheel that int( ) uses
is compiler dependent. The limit will probably be 2^63 on the newer machines
that are coming out, and probably 2^15 on antiques using 8086 code.




"Jaap Frank" <jjf### [at] xs4allnl> wrote in message
news:3ec1797c$1@news.povray.org...
> Hello,
>
> when I was testing how I can translate a float like
>
> 1.23456789e-28
>
> into a 6 bytes notation for a ppm file I noticed that
> the float function int() has a maximum value.
> Try this:
>
> *************************************
> #declare Num1 = pow(2,30);
> #declare Num2 = pow(2,31);
> #declare Num3 = pow(2,32);
> #declare Int1 = int(Num1);
> #declare Int2 = int(Num2);
> #declare Int3 = int(Num3);
> #debug concat("\nNum1 = ",str(Num1,0,-1),
>        " | Num2 = ",str(Num2,0,-1),
>        " | Num3 = ",str(Num1,0,-1))
> #debug concat("\nInt1 = ",str(Int1,0,-1),
>        " | Int2 = ",str(Int2,0,-1),
>        " | Int3 = ",str(Int3,0,-1),"\n")
> *************************************
> The result for me was:
>
> Persistence of Vision(tm) Ray Tracer Version 3.5 win32 (.icl)
> ....
> Num1 = 1073741824.000000 | Num2 = 2147483648.000000 | Num3 =
1073741824.000000
> Int1 = 1073741824.000000 | Int2 = -2147483648.000000 | Int3
= -2147483648.000000
>
> There is no warning about a max value in the manual.
> Maybe it is wise to do this.
>
> Jaap Frank
>
>

Post a reply to this message

Correction to earlier post:

#declare f = ( f < 0 ? -tmp : tmp);

Post a reply to this message

In article <3ec25305@news.povray.org> , "Will W" <wil### [at] NOSPAMwizzardsnet>
wrote:

> So, this demonstrates this implementation of POV represents integers with a
> 32 bit number wheel, that wraps from positive to negative values at 2 raised
> to the 31st power (2^31, 2**31, or pow(2,31). This is of course because the
> high order bit is used as a sign bit.

Nobody ever said POV-Ray offers infinite precision.  To the contrary, it has
been said very often that very small or very big numbers when used will not
always produce the desired results.

    Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> Nobody ever said POV-Ray offers infinite precision.  To the contrary, it has
> been said very often that very small or very big numbers when used will not
> always produce the desired results.

  I still think that (C's) floor() should be used instead of (C's) int()
for the POV-Ray int() function.
  Since you can represent 5000000000.25 with povray's identifier, I don't
see any reason why POV-Ray's int() should not return 5000000000.

  (Or better "x<0 ? -floor(-x) : floor(x)" to maintain the same behaviour.)

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

In article <3ec23a4f@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   Rounding would change its behaviour, which might not be good (eg. int(0.6)
> would now give 1 instead of 0).
> 
>   If the different behaviour of floor() with regard to negative values is
> a problem, then the solution is easy: x<0 ? -floor(-x) : floor(x)

You're right, rint() doesn't do what I thought it did. Your expression 
should do the right thing without stomping on the precision. Perhaps 
adding a separate round() or rint() built-in function would be useful as 
well.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

I found more unexpected limitations:

When using the functions mod(A,B) and div(A,B)
you can't give values for A greater then int(float),
else the results are wrong.
Obviously both functions needs integer values.
Maybe a hint in the manual about the integer functions
is needed.

Jaap Frank

Post a reply to this message