math argument reduction

math argument reduction

[Szabolcs Nagy]

dalias, i thought about the simple argument reduction method
you proposed on irc, imho it won't be that good

the task is to calculate X mod M, so to get the fractional part of
x = X/M
you said you would treat X as a sum (of 2^n terms) let's say
X = A+B
and assume we have precalculated a=A/M and b=B/M in a table, then
x = a+b
is easy to get

but it well might be that the form of a+b is

[..]1011 . 0000000000000001101011[..]

so the fractional part has many leading zeros
(it can be as many as 61) so you need to store a and b
with large precision to get good floating point representation
of the fractional part
(53 + 61 bits precision + some extra bits for rounding)

so you need to store and do arithmetics with 120bit fixpoint values

at that point it's probably not much harder to implement
the standard method of argument reduction used in sun
and bsd libm:

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.67.5616

Re: math argument reduction

[Rich Felker]

On Sun, Jun 26, 2011 at 08:04:02PM +0200, Szabolcs Nagy wrote:
> dalias, i thought about the simple argument reduction method
> you proposed on irc, imho it won't be that good
> 
> the task is to calculate X mod M, so to get the fractional part of
> x = X/M
> you said you would treat X as a sum (of 2^n terms) let's say
> X = A+B
> and assume we have precalculated a=A/M and b=B/M in a table, then
> x = a+b
> is easy to get
> 
> but it well might be that the form of a+b is
> 
> [..]1011 . 0000000000000001101011[..]
> 
> so the fractional part has many leading zeros
> (it can be as many as 61) so you need to store a and b
> with large precision to get good floating point representation
> of the fractional part
> (53 + 61 bits precision + some extra bits for rounding)
> 
> so you need to store and do arithmetics with 120bit fixpoint values

I think you misunderstood my algorithm. You never need to compute X/M.
It's A%M and B%M, not A/M and B/M, which you have precalculated in
your tables. And therefore, (A+B)%M is congruent to A%M + B%M. In
general it could be outside the interval [0,M), but not by so much
that it's hard to get a good answer.

Rich

Re: math argument reduction

[Szabolcs Nagy]

* Rich Felker <dalias@aerifal.cx> [2011-06-26 14:33:44 -0400]:
> It's A%M and B%M, not A/M and B/M, which you have precalculated in
> your tables. And therefore, (A+B)%M is congruent to A%M + B%M. In
> general it could be outside the interval [0,M), but not by so much
> that it's hard to get a good answer.

the hard part is when there is a lot of leading zeros in the result

A%M + B%M can be just above M by a little so (A%M+B%M)%M is almost 0
eg: 0.00000000000000011111
to represent this number properly as float you need all those 1s eg
1.1111 * 2^-n

if A%M and B%M is not precise enough then those trailing 1s will get
lost so the abs value is about right but as a floating point value
the result does not have 53 correct bits..