POV-Ray : Newsgroups : povray.bugreports : calculus bug in PovRay3.1 Server Time
22 Dec 2024 18:45:10 EST (-0500)
  calculus bug in PovRay3.1 (Message 1 to 6 of 6)  
From: Uwe Zimmermann
Subject: calculus bug in PovRay3.1
Date: 22 Jun 1999 04:23:19
Message: <376F47F5.89E8568D@ele.kth.se>
Hello List,

yesterday I installed the 3.1e version of PovRay on my Windows NT4 sp3
computer and discovered a bug in the mathematics part of PovRay:

the mod(A,B) function is meant to provide the modulus of A divided by B.
Per definition the modulus is a NON-NEGATIVE INTEGER value. However if
you ask PovRay to perform modulus calculations with A being negative you
get a negative result:

                PovRay        definition

mod(0,5)          0                0        OK
mod(1,5)          1                1        OK
mod(2,5)          2                2        OK
mod(3,5)          3                3        OK
mod(4,5)          4                4        OK
mod(5,5)          0                0        OK
mod(6,5)          1                1        OK
mod(7,5)          2                2        OK

BUT

mod(0,5)          0                0        OK
mod(-1,5)        -1                4        WRONG
mod(-2,5)        -2                3        WRONG
mod(-3,5)        -3                2        WRONG
mod(-4,5)        -4                1        WRONG
mod(-5,5)         0                0        WRONG
mod(-6,5)        -1                4        WRONG
mod(-7,5)        -2                3        WRONG

as I noticed this bug was already present in v3.0 of PovRay for win32
and thus I'm wondering if it's a bug or a feature. At least it should be
noted in the documentation that PovRay does not use the standard
definition of the modulus calculation.


Uwe.

-------------------------------------------------
Uwe Zimmermann                uwe### [at] geocitiescom	
Dipl. Phys.                     uwe### [at] elekthse 

           Department of Electronics
            Solid State Electronics
         Royal Institute of Technology
                 Electrum 229
           S-16440 Kista-Stockholm
                   Sweden

http://www.ele.kth.se/FTE/personal/pers_uwe.html
------------------------------------------------


Post a reply to this message

From: Axel Baune
Subject: Re: calculus bug in PovRay3.1
Date: 22 Jun 1999 06:08:23
Message: <376F6091.79B6E70B@neuro.informatik.uni-ulm.de>
Uwe Zimmermann wrote:

> the mod(A,B) function is meant to provide the modulus of A divided by B.
> Per definition the modulus is a NON-NEGATIVE INTEGER value. However if
> you ask PovRay to perform modulus calculations with A being negative you
> get a negative result:

...

> as I noticed this bug was already present in v3.0 of PovRay for win32
> and thus I'm wondering if it's a bug or a feature. At least it should be
> noted in the documentation that PovRay does not use the standard
> definition of the modulus calculation.

I think you are wrong. As from my crypography course I know a definition
for modulus, which also allows negative return values. The modulus function
of POV just behaves as I know it from the cryptography course. So I think
the POV modulus function is correct.

By the way if you want always positive modulus values than simply calculate

mod(A,B) if A is positive and
B+mod(A,B) if A is negative

This should give you the definition you know for the moduls function.

Yours Axel


Post a reply to this message

From: Thorsten Froehlich
Subject: Re: calculus bug in PovRay3.1
Date: 22 Jun 1999 08:17:09
Message: <376f7ec5@news.povray.org>
In article <376F47F5.89E8568D@ele.kth.se> , Uwe Zimmermann <uwe### [at] elekthse>
wrote:

> Hello List,
>
> yesterday I installed the 3.1e version of PovRay on my Windows NT4 sp3
> computer and discovered a bug in the mathematics part of PovRay:
>
> the mod(A,B) function is meant to provide the modulus of A divided by B.
> Per definition the modulus is a NON-NEGATIVE INTEGER value. However if
> you ask PovRay to perform modulus calculations with A being negative you
> get a negative result:
>
>                 PovRay        definition
>
> mod(0,5)          0                0        OK
> mod(1,5)          1                1        OK
> mod(2,5)          2                2        OK
> mod(3,5)          3                3        OK
> mod(4,5)          4                4        OK
> mod(5,5)          0                0        OK
> mod(6,5)          1                1        OK
> mod(7,5)          2                2        OK
>
> BUT
>
> mod(0,5)          0                0        OK
> mod(-1,5)        -1                4        WRONG
> mod(-2,5)        -2                3        WRONG
> mod(-3,5)        -3                2        WRONG
> mod(-4,5)        -4                1        WRONG
> mod(-5,5)         0                0        WRONG
> mod(-6,5)        -1                4        WRONG
> mod(-7,5)        -2                3        WRONG
>
> as I noticed this bug was already present in v3.0 of PovRay for win32
> and thus I'm wondering if it's a bug or a feature. At least it should be
> noted in the documentation that PovRay does not use the standard
> definition of the modulus calculation.

You are right that the C library fmod function (which the POV-Ray mod
function is based on) does not return the mathmatically defined values of a
modulus operation. This is simply the way this POV-Ray function is defined
(because of the internal representation of floating point numbers).


     Thorsten


Post a reply to this message

From: Ralf Muschall
Subject: Re: calculus bug in PovRay3.1
Date: 22 Jun 1999 21:04:14
Message: <3770323E.54D8BCA4@t-online.de>
Axel Baune schrieb:

> I think you are wrong. As from my crypography course I know a definition
> for modulus, which also allows negative return values. The modulus function

In math, they usually call this "remainder", defined like
rem(a,b)=a-b*trunc(a/b).

The modulus is defined as Uwe wrote, i.e.
mod(a,b)=a-b*floor(a/b)

Compilers etc. just say
practicalmod(a,b)=a-b*int(a/b)

where int() is required to act like floor() on positive
arguments and left to the implementor for negative ones.
Ususally it behaves like trunc(), since this is what chips
do.

Ralf


Post a reply to this message

From: Nieminen Mika
Subject: Re: calculus bug in PovRay3.1
Date: 23 Jun 1999 09:24:52
Message: <3770e024@news.povray.org>
Uwe Zimmermann <uwe### [at] elekthse> wrote:

:                 PovRay        definition

: mod(-5,5)         0                0        WRONG

  Both povray and definition are wrong?-)

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/


Post a reply to this message

From: Uwe Zimmermann
Subject: Re: calculus bug in PovRay3.1
Date: 23 Jun 1999 12:50:25
Message: <3771104F.401AA77C@ele.kth.se>
Nieminen Mika wrote:
> 
> :                 PovRay        definition
> 
> : mod(-5,5)         0                0        WRONG
> 
>   Both povray and definition are wrong?-)

Sorry - Cut and Paste Error 101   ;-))


Uwe.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.