"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