 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3e6cc573@news.povray.org> , gimi <gim### [at] psicoch> wrote:
> - then consider this:
> (source: http://www.cs.uu.nl/~daan/papers/divmodnote.html)
Because someone on some webpage says this makes my statement incorrect?
I am not going to get into an argument over nonsense like this. Any such
argument would be pointless because I don't have do defend correct behavior.
You have to produce credible sources that show the current behavior does not
follow any logical rules. And that task, fortunately, is impossible because
the results in POV-Ray are generated by a well-defined program.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3e6cc573@news.povray.org> , gimi <gim### [at] psicoch> wrote:
> this is what both the programmers of povray, and the engineers
> at hp did, and why the results are different, but neither are
> *wrong*!
Yes, because you only look at div and mod as one system. You have to
consider the use of div without mod. And then the rounding rules get
arbitrary as a special case just to fit mod, which in nonsense to do. And
just because engineers at HP didn't know how to produce a logical
implementation doesn't make their implementation right.
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:
> In article <3e6cc573@news.povray.org> , gimi <gim### [at] psicoch> wrote:
>>(source: http://www.cs.uu.nl/~daan/papers/divmodnote.html)
>
> Because someone on some webpage says this makes my statement incorrect?
no, it's that it is *plain wrong* that makes it incorrect.
your statement was that Anders was wrong, and i showed
that this is is not true. - get it?
i quoted this page because it was the first hit
on google. i looked this up because i wasn't sure
about the details, so i refreshed my memory, kind of.
what pages i quote is completely irrelevant, as long as
the content is correct. i just couldn't find it in one
of my books right away.
> I am not going to get into an argument over nonsense like this. Any such
> argument would be pointless because I don't have do defend correct behavior.
> You have to produce credible sources that show the current behavior does not
> follow any logical rules. And that task, fortunately, is impossible because
> the results in POV-Ray are generated by a well-defined program.
again, you missed by far! - nowhere and in no way did i
suggest that povray (nor any other program or system) did
not behave correctly - i quote again:
Thorsten Froehlich wrote:
> In article <3e6bcf10@news.povray.org> , "Anders K."
> <and### [at] kaseorgcom> wrote:
>> 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.
see, you accused Anders of stating something wrong.
i said that no, it is not wrong. it is a matter of
how you actually define that functions, and if you
do it Anders' way, you will get his results, which
are as correct as povray's or hp's results are, because
they fulfill the relation in the definition that i
have quoted.
Thorsten Froehlich wrote:
> In article <3e6cc573@news.povray.org> , gimi <gim### [at] psicoch> wrote:
>> this is what both the programmers of povray, and the engineers
>> at hp did, and why the results are different, but neither are
>> *wrong*!
>
> Yes, because you only look at div and mod as one system. You have to
> consider the use of div without mod. And then the rounding rules get
> arbitrary as a special case just to fit mod, which in nonsense to do.
> And just because engineers at HP didn't know how to produce a logical
> implementation doesn't make their implementation right.
honestly, i don't see where you are trying to get here.
of course the two functions have to be defined on the basis
of the same system, or they would not work (as they have to
sort of "complement" each other). - you cannot use two
different rulesets for creating "div" and "mod" functions;
as they will not generally fulfull the equation in the
definition this way (like using "hp-div" together with
"povray-mod", or whatever).
it is not a question of right or wrong, logical or illogical
implementation. the question is whether they are consistently
defined, and if they are, they will actually work!
well, i'm going to drink some beer now. cheers!
--
the quote has left the building
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Oh my God, what have I created...
Well, of course, div and mod could give me any pair of numbers such that you
can reconstruct the originals! Of course, letting mod be larger than the
denominator would seem a little silly from a practical point of view, but
yes, I am aware that there are two equally valid ways PR could handle this -
which is why I asked!
I too would have liked to find that it does it the other way round - because
I wanted to use mod() to reduce all integer values into the range 0 - (n-1).
Never mind!
Andrew.
PS. What the hell is "speficy"?!? 8¬0
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3e6cf18e$1@news.povray.org> , gimi <gim### [at] psicoch> wrote:
> honestly, i don't see where you are trying to get here.
>
> of course the two functions have to be defined on the basis
> of the same system, or they would not work (as they have to
> sort of "complement" each other). - you cannot use two
> different rulesets for creating "div" and "mod" functions;
> as they will not generally fulfull the equation in the
> definition this way (like using "hp-div" together with
> "povray-mod", or whatever).
The point is that the non-POV-Ray results are plain useless for anything but
combining mod and div results back together. However, it might be
surprising, but the mod and div functions exist for more than just
mathematical completeness.
Apart from this, I really have no time for this.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I wrote:
> > div(7, 3) = 2
> > div(-7, 3) = -3
> > div(7, -3) = -2
> > div(-7, -3) = 3
Thorsten Froehlich wrote:
> 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.
No, the formulas I'm using are very simple and consistent:
div(a, b) = floor(a / b)
mod(a, b) = a - div(a, b)
Where floor always rounds down to the nearest integer.
Instead of floor, POV-Ray is using trunc (which POV-Ray calls int, but
shouldn't), and trunc rounds up if a number's less than zero, and down if a
number's greater than zero. So it's POV-Ray's current behavior that uses
different rounding rules, and in your own words, is nonsensical.
Anders
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
> The point is that the non-POV-Ray results are plain useless for anything
but
> combining mod and div results back together.
I (and many others) would say that about the current POV-Ray results! Rune
has already given an example where the POV-Ray behavior is useless -- taking
a hue value mod 360, attempting to get it in the range [0, 360). Now I'd
like to see an example where the current POV-Ray behavior is needed. Anyone?
Anders
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Anders K." <and### [at] kaseorgcom> wrote in message
news:3e6d50e4@news.povray.org...
<snip>
> Instead of floor, POV-Ray is using trunc (which POV-Ray calls int, but
> shouldn't), and trunc rounds up if a number's less than zero, and down if
a
> number's greater than zero. So it's POV-Ray's current behavior that uses
> different rounding rules, and in your own words, is nonsensical.
POV's method is consistent within its intended framework. The behavior is
that truncation is always to the lower magnitude, which often is what you
want when working in a cartesian coordinate system (where the negation of a
value should be a symmetrical with the first value around the origin).
Because POV is essentially a cartesian graphing system, it makes a lot of
sense to go with this model.
Another aspect of the problem that is going unrecognized here is that while
mathemeticians deal with a true integer number line, there is no way to
represent that number line in any computer I know of. The best that can be
done is to set up a large "number circle"-- but there will be some maximum
number which when incremented will yield a negative number, and some minimum
number which when decremented will yield a positive number. Working with
magnitudes-- the distance the number is away from zero-- allows for more
consistency in the system's behavior.
I'm not sure that I'd care to see POV adopt the pure mathematics model.
While it is true that the current method makes conversion of negative hue
values more difficult, it also makes operations in POV's vector space more
dwim. I'm sort of confused about negative hue values anyway-- the concept
strikes me as unnatural. But whatever floats your boat.
--
Will Woodhull
Thornhenge, SW Oregon, USA
willl.at.thornhenge.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
> The point is that the non-POV-Ray results are plain useless for anything but
> combining mod and div results back together.
that is bullshit. i won't look for a page to quote
from this time :) , but i bet there are plenty.
or maybe you should look up "modulo calculus" for
yourself.
> However, it might be
> surprising, but the mod and div functions exist for more than just
> mathematical completeness.
yes, i understand this now (Will's explanation was
very helpful for my understanding of povray's use
for div and mod, and why it is a little, um,
"different". ;)
however, i agree with Andrew that it is a bit strange
from a mathematician's perspective.
the only solution would be to use macros for other
implementations, if one needs them, as hardly anybody
would agree if someone asked the pov team to rename,
say, "div" to "symdiv" and add another function..
> Apart from this, I really have no time for this.
i disagree! ;)
g.
--
Shick's Law: There is no problem a good miracle can't solve.
++ mailto:gim### [at] psicoch ++ http://www.psico.ch/ ++
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Will W wrote:
> POV's method is consistent within its intended framework. The behavior is
> that truncation is always to the lower magnitude, which often is what you
> want when working in a cartesian coordinate system (where the negation of
a
> value should be a symmetrical with the first value around the origin).
I don't see why anyone would want mod(-x, m) to be symmetrical with mod(x,
m).
> Another aspect of the problem that is going unrecognized here is that
while
> mathemeticians deal with a true integer number line, there is no way to
> represent that number line in any computer I know of. The best that can be
> done is to set up a large "number circle"-- but there will be some maximum
> number which when incremented will yield a negative number, and some
minimum
> number which when decremented will yield a positive number.
That's not true with floating-point numbers, which is what we're talking
about here. Besides, even if they were integers, the result of mod(-1, 3) is
much more important than the result of mod(-2147483648, 3).
> While it is true that the current method makes conversion of negative hue
> values more difficult, it also makes operations in POV's vector space more
> dwim.
How so?
> I'm sort of confused about negative hue values anyway-- the concept
> strikes me as unnatural.
Of course you wouldn't directly enter a negative hue, but suppose you want
to shift all the hues in some picture down by 10 -- then you get negative
hues pretty quickly. If you prefer, think of shifting an angle by 10
degrees. This is exactly the kind of thing that mod is for, but POV-Ray's
mod is nearly useless in this case.
Anders
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Anders K." <and### [at] kaseorgcom> wrote in message
news:3e6dec0b@news.povray.org...
> Will W wrote:
> > POV's method is consistent within its intended framework. The behavior
is
> > that truncation is always to the lower magnitude, which often is what
you
> > want when working in a cartesian coordinate system (where the negation
of
> a
> > value should be a symmetrical with the first value around the origin).
>
> I don't see why anyone would want mod(-x, m) to be symmetrical with mod(x,
> m).
In CSG operations or modifying material maps and so forth, yes, I would
prefer that the arithmetic be symmetrical around the origin. That lets me
get away with a lot of shortcuts since I can then often ignore the direction
of opposing vectors and just work with their magnitudes.
> > Another aspect of the problem that is going unrecognized here is that
> while
> > mathemeticians deal with a true integer number line, there is no way to
> > represent that number line in any computer I know of. The best that can
be
> > done is to set up a large "number circle"-- but there will be some
maximum
> > number which when incremented will yield a negative number, and some
> minimum
> > number which when decremented will yield a positive number.
>
> That's not true with floating-point numbers, which is what we're talking
> about here. Besides, even if they were integers, the result of mod(-1, 3)
is
> much more important than the result of mod(-2147483648, 3).
Uh, no, I was talking about integers, with integer arithmetic like mod( )
and div( ). I don't know any number system that uses a mod( ) or div( ) with
rationals or reals... it sounds sort of interesting. But I don't have the
time or inclination to explore esoteric mathematics (I'm not a
mathematician). And I don't think the POV news groups are the best forum for
such a discussion anyway.
At this point, I fail to see any value in continuing this conversation. We
are no longer using a common terminology, and we are drifting too far from
the purposes of this forum.
--
Will Woodhull
Thornhenge, SW Oregon, USA
willl.at.thornhenge.net
PS-- don't be confused by POV's way of representing all integers as reals.
They aren't, you know. POV's way of doing things is just another of those
shortcuts engineers like to use to make things practical.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Will W wrote:
> In CSG operations or modifying material maps and so forth, yes, I would
> prefer that the arithmetic be symmetrical around the origin. That lets me
> get away with a lot of shortcuts since I can then often ignore the
direction
> of opposing vectors and just work with their magnitudes.
Sounds like you're just being lazy, typing mod(x, m) when you should
type -mod(-x, m) -- it's only two extra characters. If that's not what it
is, can you give a more concrete example, like Rune did?
> Uh, no, I was talking about integers, with integer arithmetic like mod( )
> and div( ). I don't know any number system that uses a mod( ) or div( )
with
> rationals or reals...
Actually, mod and div are perfectly well defined on reals: div counts the
greatest integer multiple of b that's at most a, and it is perfectly
possible to consider integer multiples of fractions. You can use exactly the
same formulas:
div(a, b) = floor(a / b)
mod(a, b) = a - div(a, b)
Although I just checked in POV-Ray, and it does seem to convert everything
to an integer right now. That's too bad, since mod and div would be useful
with non-integer values (such as angles mod 2*pi), and it also has the
unfortunate side effect that div(10000000000000000000000, 3) = -2147483648.
Anders
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
