 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
What do div() and mod() do in the case of negative numerator/denominator?
The docs don't seem to speficy...
Thanks.
Andrew.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Andrew Coppin" <orp### [at] btinternet com> wrote in message
news:3e6bae4c@news.povray.org...
> What do div() and mod() do in the case of negative numerator/denominator?
> The docs don't seem to speficy...
Rather than giving away the answer, I think a lesson in fishing is in order.
Look into #debug and the debugging text stream, and expecially into the
str(a,b,c) function, and I think you'll find a way to work out the answer on
your own, in a few short, and very worthwhile, minutes. You'll then also
know how to explore a whole host of other POV questions on your own.
If you still run into trouble, why don't you post back on povray.newusers?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Andrew Coppin wrote:
> What do div() and mod() do in the case of negative numerator/denominator?
POV-Ray's answers are:
div(7, 3) = 2 mod(7, 3) = 1
div(-7, 3) = -2 mod(-7, 3) = -1
div(7, -3) = -2 mod(7, -3) = 1
div(-7, -3) = 2 mod(-7, -3) = -1
whereas the correct answers are:
div(7, 3) = 2 mod(7, 3) = 1
div(-7, 3) = -3 mod(-7, 3) = 2
div(7, -3) = -2 mod(7, -3) = 1
div(-7, -3) = 3 mod(-7, -3) = 2
This has annoyed me a lot. If they fixed the broken gradient pattern, why
can't they fix the equally broken div() and mod() functions?
Anders
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3e6bcf10@news.povray.org>, "Anders K." <and### [at] kaseorgcom>
wrote:
> This has annoyed me a lot. If they fixed the broken gradient pattern, why
> can't they fix the equally broken div() and mod() functions?
Because they didn't know about it?
--
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 wrote:
> Anders K. wrote:
>> This has annoyed me a lot. If they fixed the
>> broken gradient pattern, why can't they fix
>> the equally broken div() and mod() functions?
>
> Because they didn't know about it?
The way the mod() function works for negative numbers has annoyed me a
lot too, but having originally learned about the mod() function through
POV-Ray, I thought it was just the way it was supposed to work, pleasant
or not.
Actually, if you look in colors.inc in the CH2RGB macro, you will see
that I explicitly worked around the problem by having this line
#local H = mod(H, 360);
be followed by this one:
#local H = (H < 0 ? H+360 : H);
Internally, isn't it just some int() call that should be replaced with
floor()? From the docs:
mod(A,B) Value of A modulo B. Returns the remainder
after the integer division of A/B.
Formula is mod=((A/B)-int(A/B))*B.
Rune
--
3D images and anims, include files, tutorials and more:
rune|vision: http://runevision.com (updated Oct 19)
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Anders K." <and### [at] kaseorgcom> wrote in news:3e6bcf10@news.povray.org:
> Andrew Coppin wrote:
>> What do div() and mod() do in the case of negative
>> numerator/denominator?
>
> POV-Ray's answers are:
>
> div(7, 3) = 2 mod(7, 3) = 1
> div(-7, 3) = -2 mod(-7, 3) = -1
> div(7, -3) = -2 mod(7, -3) = 1
> div(-7, -3) = 2 mod(-7, -3) = -1
>
> whereas the correct answers are:
>
> div(7, 3) = 2 mod(7, 3) = 1
> div(-7, 3) = -3 mod(-7, 3) = 2
> div(7, -3) = -2 mod(7, -3) = 1
> div(-7, -3) = 3 mod(-7, -3) = 2
>
> This has annoyed me a lot. If they fixed the broken gradient pattern, why
> can't they fix the equally broken div() and mod() functions?
I think that the implementation of these operators may differ
from system to system.
Therefore there might be no "correct answers" for negative and
fractional operands.
Note that both POV-Ray's answers and the "correct answers"
above make sure that:
div(N, D) * D + mod(N, D) = N
I.E.:
div( 7, 3) * 3 + mod( 7, 3) = 2 * 3 + 1 = 2 * 3 + 1 = 7
div(-7, 3) * 3 + mod(-7, 3) = -2 * 3 + -1 = -3 * 3 + 2 = -7
div( 7,-3) *-3 + mod( 7,-3) = -2 *-3 + 1 = -2 *-3 + 1 = 7
div(-7,-3) *-3 + mod(-7,-3) = 2 *-3 + -1 = 3 *-3 + 2 = -7
Maybe one should test if the rule also holds for fractional
numbers in POV-Ray.
Btw.: My Hewlett Packard calculator; HP48SX, says:
7 3 MOD -> 1
-7 3 MOD -> 2
7 -3 MOD -> -2
-7 -3 MOD -> -1
(It does not have a DIV operator.)
I just did a google search:
http://www.google.com/search?q=MOD+implementation+%22negative+numbers%22
- and found this:
http://mathforum.org/library/drmath/view/52343.html
(It seems to be very relevant, but I'm to tired to read it
right now.)
Tor Olav
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I've read yours and other comments here with interest.
In practical terms there is no general rule that can be applied to integer
division or the modulo operator with negative numbers. Mathematicians
currently favor a "truncate toward negative infinity" model while engineers
have traditionally favored a "truncate toward zero" model-- since the
engineers are the ones who built all the early compilers, their approach has
been dominant in computers. It's another one of those areas where the
mathemeticians yell "I'm right!" and the engineers yell back "You can be
dead right! Our way builds safer bridges!"
The most one can expect from an interpreter, compiler, or even a spreadsheet
when using these operations is that it be self-consistent. POV-Ray appears
to be self-consistent. I don't think it's any big thing that it departs from
mathematical purity-- it is in good company. Anyone who is going to get into
esoteric stuff like taking the modulus of negative numbers needs to test how
the platform they are working on implements that function. In the drug
dosage work I used to do with spreadsheets, I learned to look for other
approaches so that Quattro and Lotus 1-2-3 would give the same results. I'm
too new to ray tracing to know for sure, but I suspect that any division
operation on a negative number can be avoided by using a different approach.
At least POV-Ray's pow( ) function avoids the ambiguities of -2^2, whose
"correct" answer is often compiler dependent. On whether the negation sign
is treated as a unary operator of highest precedence or as the equivalent of
multiplying by negative one, which is a lower precedence.
"Tor Olav Kristensen" <tor_olav_kCURLYAhotmail.com> wrote in message
news:Xns### [at] 204213191226...
> "Anders K." <and### [at] kaseorgcom> wrote in news:3e6bcf10@news.povray.org:
>
> > Andrew Coppin wrote:
> >> What do div() and mod() do in the case of negative
> >> numerator/denominator?
> >
> > POV-Ray's answers are:
<snip good stuff>
> http://mathforum.org/library/drmath/view/52343.html
>
> (It seems to be very relevant, but I'm to tired to read it
> right now.)
It is very relevant, but keep in mind it is written by a mathematician and
doesn't present the engineering view.
--
Will Woodhull <<NOT an engineer-- just an RN with some odd work history>>
Thornhenge, SW Oregon, USA
willl.at.thornhenge.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3e6bcf10@news.povray.org> , "Anders K." <and### [at] kaseorgcom>
wrote:
> This has annoyed me a lot. If they fixed the broken gradient pattern, why
> can't they fix the equally broken div() and mod() functions?
Because they are not broken. This is the correct and thus expected
behavior.
> div(7, 3) = 2
> div(-7, 3) = -3
> div(7, -3) = -2
> div(-7, -3) = 3
How can the result possibly be +-3 for any of these? No matter how you
round, this makes only sense if you apply *different* rounding rules
depending on the signs. And doing so is nonsensical.
> mod(7, 3) = 1
> mod(-7, 3) = 2
> mod(7, -3) = 1
> mod(-7, -3) = 2
Again, only if you apply random rules you could arrive at this result. I
could understand you argue for 1,2,2,1 as results for this, but not 1,2,1,2
because that is definitely wrong.
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 wrote:
> In article <3e6bcf10@news.povray.org> , "Anders K." <and### [at] kaseorgcom>
> wrote:
>>This has annoyed me a lot. If they fixed the broken gradient pattern, why
>>can't they fix the equally broken div() and mod() functions?
>
> Because they are not broken. This is the correct and thus expected
> behavior.
>
>>div(7, 3) = 2
>>div(-7, 3) = -3
>>div(7, -3) = -2
>>div(-7, -3) = 3
>
> How can the result possibly be +-3 for any of these? No matter how you
> round, this makes only sense if you apply *different* rounding rules
> depending on the signs. And doing so is nonsensical.
>
>>mod(7, 3) = 1
>>mod(-7, 3) = 2
>>mod(7, -3) = 1
>>mod(-7, -3) = 2
>
> Again, only if you apply random rules you could arrive at this result. I
> could understand you argue for 1,2,2,1 as results for this, but not 1,2,1,2
> because that is definitely wrong.
why? - ah yes, because *you* say so! ;)
- then consider this:
(source: http://www.cs.uu.nl/~daan/papers/divmodnote.html)
: For any two real numbers D (dividend) and d (divisor) with d != 0,
: there exists a pair of numbers q (quotient) and r (remainder) that
: satisfy the following basic conditions of division:
: (1) q [is an Element of] Z (the quotient is an integer)
: (2) D = d*q + r (division rule)
: (3) |r| < |d|
i think we all agree on that. - so, we can define two functions
(or operators, if you prefer "a + b" over "add(a,b)"), 'div' and
'mod', in order to find q and r for any given D and d:
: q = D div d
: r = D mod d
still no problem. - but unfortunately, this is as far as
the definitions go. as you can easily verify, there may
be more than one solution for a pair (q, r) which satisfy
the above conditions (1)-(3)!
- so, if what Anders wrote is wrong, then *at least one*
of the following equations must be false:
7 = 3 * 2 + 1
-7 = 3 * -3 + 2
7 = -3 * -2 + 1
-7 = -3 * 3 + 2
but, in fact, all are correct. - as my source puts it, this
is because..
: The above conditions don't enforce a unique pair of numbers
: q and r: When div and mod are defined as functions, one has
: to choose a particular pair q and r that satisfy these conditions.
: It is this choice that causes the different definitions found in
: literature and programming languages.
- which is also basically the same statement that Will already made.
in other words: you have to add another rule to this system
in order to make those functions "well-defined" (i hope that
is correct for the german "wohldefiniert" :) - meaning that
if you want a real function that "behaves properly" and returns
the same result for the same input every time, you *must* choose
a way to reduce this ambiguity.
this is what both the programmers of povray, and the engineers
at hp did, and why the results are different, but neither are
*wrong*!
HTH,
g.
--
"I never trust a fighting man who doesn't smoke or drink."
-- Adm William Halsey
++ mailto:gim### [at] psicoch ++ http://www.psico.ch/ ++
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sun, 9 Mar 2003 12:45:27 -0000, "Andrew Coppin" <orp### [at] btinternetcom>
wrote:
> What do div() and mod() do in the case of negative numerator/denominator?
It does operations delivered by C++ libraries/compilers.
> The docs don't seem to speficy...
You have to look into standard libc libraries documentations used to compile
your binary. Quoting POV sources:
for regular SDL expressions:
case DIV_TOKEN:
Parse_Float_Param2(&Val,&Val2);
Val=(DBL) ( (int)(Val/Val2) );
break;
case MOD_TOKEN:
Parse_Float_Param2(&Val,&Val2);
Val = fmod(Val,Val2);
break;
for functions:
Sys2 POVFPU_Sys2Table[] =
{
pow, // 0
atan2, // 1
fmod, // 2
math_div, // 3
NULL
};
SYS_MATH_RETURN math_div(SYS_MATH_PARAM i1, SYS_MATH_PARAM i2)
{
return (SYS_MATH_RETURN)((int)(i1/i2));
}
How dividing in div() works you probably know
What fmod does you can check in online manuals like:
http://www.cplusplus.com/ref/cmath/fmod.html
http://www.gnu.org/manual/glibc-2.2.5/html_node/Remainder-Functions.html
http://www.delorie.com/djgpp/doc/libc-2.02/libc_294.html
http://www.digitalmars.com/rtl/math.html#fmod
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
