David Rush wrote: > Well, the man page on my Debian Etch says that FLT_MIN == DBL_MIN == > LDBL_MIN == 1E-37, which seems silly but there you go. In any case, > the cos approximation is rather less accurate than any of those > minima.
You need to understand that Larceny's value for (acos 0) is the best IEEE double precision approximation to pi/2. It is not pi/2, however, so the cos procedure correctly returns a nonzero value for (acos 0). If cos were to return 0.0 for (acos 0), then cos would be *less* accurate than is currently the case. > Naah, I figured that part out already. What I'm really looking for is > a way to minimize the roundoff error in trig functions (so I can > actually find the zeros). It's looking like reducing all trig > evaluations to the +x+y quadrant and using symmetry to return to the > actual value might be the best answer. _Numerical Recipes_ also > recommends using a mutant recurrence relation for iterating sines and > cosines over equally spaced angular samples, and I'm thinking of > trying that. As explained above, the only way to do better is to use more precision throughout, or to use something other than binary floating point. Larceny will continue to represent inexact reals in IEEE floating point. Given that design decision, which is regarded as best current practice, this isn't something Larceny can fix. Will _______________________________________________ Larceny-users mailing list Larceny-users@lists.ccs.neu.edu https://lists.ccs.neu.edu/bin/listinfo/larceny-users
