Re: Fast fmodf(..., 1.0f)

jason.cipriani@xxxxxxxxx wrote:
On Jun 30, 1:19 pm, "christian.bau" <christian....@xxxxxxxxxxxxxxxxxx>
wrote:
On Jun 30, 12:44 am, "jason.cipri...@xxxxxxxxx"

<jason.cipri...@xxxxxxxxx> wrote:
Because it's a measured bottleneck in a performance-critical inner
loop... nothing premature about that...
I know the relative range of the values, I should have mentioned that.
I don't know exactly what it can be but I can guarantee it won't
exceed INT_MAX. And I'm not using this method anyways.
It is unlikely that your real problem is "calculate x mod 1 for a
gazillion different values of x". It is highly likely that looking at
the problem from a higher level will produce a faster solution by
looking at things from a completely different angle. So you should
post what you _really_ want to achieve.

I'm working with video post-processing in HSL color space and at one
stage I need to correct out-of-range hue components, where the correct
range is [0,1] (representing 0 to 360 degrees). I promise, from the
bottom of my heart, that's what I really want to achieve. I am,
indeed, looking for a way to calculate x mod 1 for a gazillion
different values of x. I'm not looking for alternative high level
algorithms. The way it works now is already correct. I promise.

Do these hue angles just arrive, warts and all, as floating-
point numbers with possibly improper ranges, or are they the
outputs of an earlier stage of processing? (That is, can you
do something differently in that earlier stage so the out-of-range
numbers are not generated in the first place? Or maybe so they're
more convenient, like sometimes >1 but never <0?) (Oh, and do
you really want [0,1] or are you looking for [0,1)?)

Also, there's a trick I learned many years ago in my days of
writing code for radars: Represent angles as unsigned integers of
a suitable width, dividing the circle into Uxxx_MAX+1 parts. (The
trick even had a name, "Binary Angular Measure," and angles were
measured in so-and-so many "bams.") The advantage, of course, is
that the wrap-around at two pi just falls out of the properties of
unsigned arithmetic with no extra effort.

--
Eric.Sosman@xxxxxxx
.