On Wed, 14 Nov 2007, Vincent Lefevre wrote: > On 2007-11-12 21:29:44 -0500, Geert Bosch wrote: > > On Nov 12, 2007, at 12:37, Michael Matz wrote: > >> * only double is implemented, hence long double and float are missing at > >> least, at least the long double would need some implementation work, > >> as you can't simply enlarge the mantissa and hope all your results are > >> still correct > > Initially, float could simply use double and cast the result. > > For double->float the results will remain correctly rounded. > > Yes, very probably, but this needs to be proven for each supported > function, due to the double rounding problem (this may take some time > for functions like pow).
As I understand the mention of moving towards automatically generating functions, crlibm might eventually be able to provide functions for float that do most computations in double but use double double for the hard cases (like functions for double presently use double double for most cases and triple double for hard cases), through automatic generation given the type used for function inputs/outputs (float in this case) and the types available for intermediate computations (double in this case) as well as information on worst cases for rounding? > > For x86, the use of -mfpmath=sse addresses most, if not all, issues > > related to excess precision for float and double. > > But not all x86 processors support SSE2. However, I suppose you can > have crlibm support for some architectures only. It also seems to me that automatic generation might help address the x86 issues as well, by providing both SSE2 versions (IEEE double as intermediate type) and x87 versions (using long double in all intermediate computations to avoid excess precision issues). > and consistent. For instance, sin(x)*sin(x) + cos(x)*cos(x) will > always be very close to 1, as mathematically expected. FWIW, Nick Maclaren once told me that many applications don't care about accurate argument reduction for large arguments to sin and cos (for many purposes the answer just need be within a few ulp of the correct answer for an argument within a few ulp of the given argument - which would allow any answer between -1 and 1 for sin and cos of large values), but may still expect that sin^2 + cos^2 is very close to 1. -- Joseph S. Myers [EMAIL PROTECTED]