POV-Ray : Newsgroups : povray.newusers : mod() and floating point division woes. :( : Re: mod() and floating point division woes. :( Server Time
13 Aug 2022 14:11:57 EDT (-0400)
  Re: mod() and floating point division woes. :(  
From: Bald Eagle
Date: 3 Sep 2018 08:35:00
Message: <web.5b8d29c9c557266e458c7afe0@news.povray.org>
dick balaska <dic### [at] buckosoftcom> wrote:

> What he said.
>
> I believe clipka told you the same thing recently. Woe be to he who
> chooses to ignore the mighty clipka.

Yes, yes - it wasn't ignored, it just wasn't fully interpreted and implemented.

I hate having 35 conversion factors for this that & the other thing.
And this was an entirely different loop that I was "extracting a value out of"
so it wasn't on the #for-#end highway, it was in the SDL suburb.
So it "seemed" different.

I'd say that this has more to do with mod(A,B) than with the loop.

I mean, there are going to be places where you need to do some floating point
math and use the result as directly as possible, otherwise you're going to be
five nested loops deep into code with 7 include files, and then the suggestion
that you "just" rewrite the code to use integers become - ridiculous.

At some point 1/5 ought to "equal 0.2" in an absolute, Boolean, true/false way,
and not some - well it's actually kinda sorta 0.2 +/- E way.

And I will point out that in diligently trying to find a suitable answer myself,
many "computer guys" in many fora have discussed mod and fmod and how it should
work just as well for floating point arguments as for integers.
And there were as many different answers as there were responders to the OP who
all argued with each other.  :|

Then there's --- the POV-Ray source code itself, where I found this:
https://github.com/POV-Ray/povray/blob/master/source/base/mathutil.h

So, I'm just trying to learn about the basics of the floating point math
problems and how to solve them, rather than just stay ignorant and try to do it
"the easy way" by avoiding them, until I one day am faced with one I HAVE to
solve.

"Don't do that" doesn't work with me.

"Here's how you deal with that kind of problem when you come across it" is much
more in line with the way I think and do things, because I'm always going to be
drilling down to the fundamental first principles and trying to understand them
at some point.

(Hugs, you little psychopath, you!)
"When Murphy crunched the numbers, he found Connecticut was the most
psychopathic state per capita, followed by California, New Jersey, and New
York/Wyoming (which were equally tied in fourth place)."
https://www.sciencealert.com/psychopath-capital-of-the-us-according-science-states-ranked-washington-dc


-------------------------------------------------------------------------------

// wrap floating-point value into the range [0..upperLimit);
// (this is equivalent to fmod() for positive values, but not for negative ones)
template<typename T>
inline T wrap(T val, T upperLimit)
{
    T tempVal = fmod(val, upperLimit);
    // NB: The range of the value computed by fmod() should be in the range
[0..upperLimit) already,
    // but on some architectures may actually be in the range [0..upperLimit].

    if (tempVal < T(0.0))
    {
        // For negative values, fmod() returns a value in the range
[-upperLimit..0];
        // transpose it into the range [0..upperLimit].
        tempVal += upperLimit;
    }

    // for negative values (and also for positive values on systems that
internally use higher precision
    // than double for computations) we may end up with value equal to
upperLimit (in double precision);
    // make sure to wrap these special cases to the range [0..upperLimit) as
well.
    if (forcePrecision<double>(tempVal) >= upperLimit)
        tempVal = T(0.0);

    // sanity check; this should never kick in, unless wrap() has an
implementation error.
    POV_MATHUTIL_ASSERT((tempVal >= 0.0) && (tempVal < upperLimit));

    return tempVal;
}


Post a reply to this message

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