pov-ray ver: 3.5.icl.win32
Sys. op: Win xp
cpu: pentium 4, 256 MB

If i do (i.e.) y= cos(x) where 0 < x < 2*pi and i'm testing the following:
   #if(y < 0)
      //block1...
   #else //block2...

the result when x= pi*3/2 is block1! And taking a look at its value, is
-0.00000 and is taken as negative number. By now i correct it simplyly
checking such y value:  #macro correct(num)(num<0?:num=0?0:num:num) #end

Can someone confirm if this is a bug? Thanks

(sorry, but my english is very bad)

Post a reply to this message

In article <web.3e319c0b7f992aa0e1b6456c0@news.povray.org> , "Jano" 
<oli### [at] hotmailcom> wrote:

> the result when x= pi*3/2 is block1! And taking a look at its value, is
> -0.00000 and is taken as negative number. By now i correct it simplyly
> checking such y value:  #macro correct(num)(num<0?:num=0?0:num:num) #end
>
> Can someone confirm if this is a bug? Thanks

No, the behavior is perfectly correct.


    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

Entre otras cosas, Jano tuvo a bien escribir:

> If i do (i.e.) y= cos(x) where 0 < x < 2*pi and i'm testing the following:
>    #if(y < 0)
>       //block1...
>    #else //block2...
> 
> the result when x= pi*3/2 is block1! And taking a look at its value, is
> -0.00000 and is taken as negative number. By now i correct it simplyly
> checking such y value:  #macro correct(num)(num<0?:num=0?0:num:num) #end
> 
> Can someone confirm if this is a bug? Thanks

What would you expect?

cos(0) = 1
cos(pi*1/2) = 0
cos(pi) = -1
cos(pi*3/2) = 0

Unfortunately, POV-Ray is not perfect and there are (as in most computer 
programs) floatin point inaccuracies and rounding errors. That means the 
result is not *exactly* 0, but slightly lower, and you see -0.000. This is 
normal and expected behaviour, if you are testing against 0 you should in 
turn test that abs(y) < tiny_number.

-- 

Linux User #289967 (counter.li.org)
PGP Pub Key ID: 0x01A95F99 (pgp.escomplinux.org)

Post a reply to this message

Jellby wrote:

>What would you expect?
>
>cos(0) = 1
>cos(pi*1/2) = 0
>cos(pi) = -1
>cos(pi*3/2) = 0
>
>Unfortunately, POV-Ray is not perfect and there are (as in most computer
>programs) floatin point inaccuracies and rounding errors. That means the
>result is not *exactly* 0, but slightly lower, and you see -0.000. This is
>normal and expected behaviour, if you are testing against 0 you should in
>turn test that abs(y) < tiny_number.
>

>Linux User #289967 (counter.li.org)
>PGP Pub Key ID: 0x01A95F99 (pgp.escomplinux.org)
>

Thak you, i'll remember it next time :)

Post a reply to this message

In article <3e31a57f@news.povray.org> , Jellby <jel### [at] M-yahoocom>  
wrote:

>
> Unfortunately, POV-Ray is not perfect and there are (as in most computer
> programs) floatin point inaccuracies and rounding errors. That means the
> result is not *exactly* 0, but slightly lower, and you see -0.000. This is
> normal and expected behaviour, if you are testing against 0 you should in
> turn test that abs(y) < tiny_number.

It isn't even a rounding error.  PI can never be represented exactly in any
evaluation (assuming certain properties of PI are indeed true).  So while
symbolically the result 0.0 is correct, numerically that cannot be reached.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:
> It isn't even a rounding error.  PI can never be represented exactly in any
> evaluation (assuming certain properties of PI are indeed true).

Sure it can.  pi = circumference/diameter
There, I just exactly represented Pi. :)

-- 
--Tim Cook
http://empyrean.scifi-fantasy.com

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------

Post a reply to this message

Timothy R. Cook wrote:
> Thorsten Froehlich wrote:
> 
>> It isn't even a rounding error.  PI can never be represented exactly 
>> in any
>> evaluation (assuming certain properties of PI are indeed true).
> 
> 
> Sure it can.  pi = circumference/diameter
> There, I just exactly represented Pi. :)

...but sybolically, not numerically. The numeric representation
is left as an exercise for the student.  8)



-- 
Steve Martin, CPBE CBNT

Post a reply to this message

"Timothy R. Cook" <tim### [at] scifi-fantasycom> wrote:
> > It isn't even a rounding error.  PI can never be represented exactly in
any
> > evaluation (assuming certain properties of PI are indeed true).
>
> Sure it can.  pi = circumference/diameter
> There, I just exactly represented Pi. :)

Sure it cannot.

Could you please specify what exactly is "circumference" in your formula
(w/o just telling it's "diameter*pi")?

Post a reply to this message