Maths constants
in [Fortran]
|
From: steve on 21 Jan 2010 01:25 On Jan 20, 9:12 pm, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote: > I don't want to get into any more arguments on the range reduction > of trig. functions, but having to multiply by pi such that the > function can then divide by pi doesn't seem so useful. One might > hope that the value returned by ACOS(-1.D0) is appropriate for the > range reduction of COS(), independent of its accuracy. The number of bits in pi that one might obtain from acos(-1.d0 is not very close to number of bits of pi needed for accurate range reduction of the argument of cos(). See for example, ARGUMENT REDUCTION FOR HUGE ARGUMENTS: Good to the Last Bit K. C. Ng and the members of the FP group of SunPro Of particular interest is this quote: Around 1982, a way of implementing the infinitely precise pi argument reduction was found independently by Bob Corbett at UC Berkeley (ref [2]) and the team of Mary H. Payne and Robert N. Hanek at Digital Equipment Corporation (ref [3]). -- steve
From: glen herrmannsfeldt on 21 Jan 2010 03:01 steve <kargls(a)comcast.net> wrote: > On Jan 20, 9:12?pm, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote: >> I don't want to get into any more arguments on the range reduction >> of trig. functions, but having to multiply by pi such that the >> function can then divide by pi doesn't seem so useful. ?One might >> hope that the value returned by ACOS(-1.D0) is appropriate for the >> range reduction of COS(), independent of its accuracy. > The number of bits in pi that one might obtain from acos(-1.d0 > is not very close to number of bits of pi needed for accurate > range reduction of the argument of cos(). See for example, > ARGUMENT REDUCTION FOR HUGE ARGUMENTS: > Good to the Last Bit > K. C. Ng and the members of the FP group of SunPro That was in the context of the FFT, where it is usual to need SIN and COS for arguments less than 2pi. Even so, it is extremely rare in scientific computing to use trig. functions of huge arguments. (There are likely a few cases in number theory where they are used, but rarely in experimental physical sciences. For those cases where they are needed, most likely the programmer will want to do range reduction in a very specific way, and not rely on the math library.) I still remember when I was in high school and a friend got a brand new HP-55 calculator. (You can figure out how long ago that was, if you want to.) One that I tried on it was sin(9.999999999e99) in degree mode, finding that the answer was not zero. My friend was not convinced that was wrong, trusting in HP to always give the right answer. Assuming that the digits past the last nine are all zeros, the value is obviously a multiple of 360, and the sine should be zero. Some time earlier, in using the SIN function with the OS/360 Fortran compiler, I receive an error message about computing SIN of a value greater than pi*2**18. I believe that was the result of either an undefined value or argument of the wrong type, but it was explained to me why one would not want to do that. (IBM allows pi*2**50 for DSIN, and pi*2*100 for QSIN.) There is not so much documentation on x87, and even less on SSE as far as how they are implemented. For IA32 x87, the argument is required to have absolute value less than 2**64. (I believe it was more restricted on the 8087 and 80287, in which case range reduction was done in software before using the x87 operations.) Given the x87 FSINCOS instruction, which simultaneously computes sin and cosine, I do wonder if they use CORDIC. (A side effect of CORDIC is that you get both out without extra cost.) (snip) -- glen
From: Richard Maine on 21 Jan 2010 03:30 glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: > Even so, it is extremely > rare in scientific computing to use trig. functions of huge arguments. Eh? What data to you base that on? I would not have said it was rare at all, much less extremely rare. I've seen plenty of cases. Take any old second order dynamic system and look at its behavior for large time and you'll be there. That's not exactly obscure. Sure, there are also other ways to do such things, but I can't buy your "extremely rare." Now in most of the cases I've seen, the result doesn't matter much because that trig function of a large argument value gets multiplied by an exponential with a similarly large (and negative) value. It has a fair chance of underflowing to zero, but is likely negligable even if it doesn't. If you ask for cases where getting an accurate value for huge arguments mattered, I don't think I've ever personally run into one and I might buy the "extremely rare". But that's a different question from the one of whether the trig function was used at all for such arguments. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: glen herrmannsfeldt on 21 Jan 2010 04:57 Richard Maine <nospam(a)see.signature> wrote: (I wrote) >> Even so, it is extremely >> rare in scientific computing to use trig. functions of huge arguments. > Eh? What data to you base that on? I would not have said it was rare at > all, much less extremely rare. I've seen plenty of cases. Take any old > second order dynamic system and look at its behavior for large time and > you'll be there. That's not exactly obscure. Sure, there are also other > ways to do such things, but I can't buy your "extremely rare." How big do you mean by big? As I said, Intel uses 2.**64 for IA32. > Now in most of the cases I've seen, the result doesn't matter much > because that trig function of a large argument value gets multiplied by > an exponential with a similarly large (and negative) value. It has a > fair chance of underflowing to zero, but is likely negligable even if it > doesn't. exp(-x) goes to zero a long time before x gets to 2.**64. > If you ask for cases where getting an accurate value for huge arguments > mattered, I don't think I've ever personally run into one and I might > buy the "extremely rare". But that's a different question from the one > of whether the trig function was used at all for such arguments. To me, huge arguments are those where x*epsilon(x) .gt. 2*pi. It seems that much work has gone into accurately computing such values. There are also large arguments, maybe in the sqrt(1/epsilon(x)) range, which I agree are useful, and should get reasonable results. -- glen
From: Clive Page on 21 Jan 2010 05:08
In message <hj91lf$pd6$1(a)naig.caltech.edu>, glen herrmannsfeldt <gah(a)ugcs.caltech.edu> writes >I still remember when I was in high school and a friend got a >brand new HP-55 calculator. (You can figure out how long ago that >was, if you want to.) One that I tried on it was sin(9.999999999e99) >in degree mode, finding that the answer was not zero. My friend >was not convinced that was wrong, trusting in HP to always give >the right answer. Assuming that the digits past the last nine are >all zeros, the value is obviously a multiple of 360, and the sine >should be zero. I still use my HP calculator, model 11C, and just tried the same thing. It returns exactly zero for sin(9.999999999e99) and exactly one for cos of it, so full marks to HP in programming their later models. If only the same standards if quality prevailed in their printer division... -- Clive Page |