On 13 February 2012 15:24, Vincent Lefevre <vincent+...@vinc17.org> wrote: > On 2012-02-10 17:41:49 +0000, Andrew Haley wrote: >> On 02/10/2012 05:31 PM, Paweł Sikora wrote: >> > it would be also nice to see functions for reducing argument range in >> > public api. >> > finally the end-user can use e.g. sin(reduce(x)) to get the best precision >> > with some declared cpu overhead. >> >> Hmm. I'm not sure this is such a terrific idea: each function has its >> own argument reduction (e.g. to [0, pi/4], [0, pi/8] or even [0, some >> weird constant that looks arbitrary but just happens to be exactly >> representable in binary]). You really don't want double rounding, >> which is what would happen with sin(reduce(x)). > > I agree. Also, range reduction may also be completely different. > The general scheme is: > > 1. Reduce the argument x (for periodic function, it is an additive > reduction, but for some other functions, it can be a multiplicative > reduction). > > 2. Compute some alternate function(s) on the reduced argument. > For the first range reduction of periodic functions, it is the > same function, but in other cases, this may be other functions. > > 3. Reconstruct the final value. Nothing to do for the first range > reduction of periodic functions, but again, this is not always > the case. >
Would it be useful to have some lib functions: remainder_2pi(x, &remainder) /* returns remainder of x / 2Pi */ remainder_pi2(x, &remainder, "ient) /* returns remainder of x / (Pi/2) with a quotient returned so you can tell where in the range [0 , 2Pi] it would fall. */ remainder_pi4(x, &remainder, "ient) /* returns remainder of x / (Pi/4), with a quotient returned. The reason for these special pi remainder functions is do with PI being need to many 100s of decimal places in order to create an accurate result so remainder(x, y) with y being set to double float PI would not be accurate enough. Kind Regards James
