 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
> In article <3e6cc573@news.povray.org> , gimi <gim### [at] psico ch> 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.
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
|
|
| |
| |
|
|
|
|
| |
|
|
