Re: The state of glibc libm
On Thu, 2012-03-15 at 03:07 +0100, Vincent Lefevre wrote: > On 2012-03-14 14:40:06 +, Joseph S. Myers wrote: > > On Wed, 14 Mar 2012, Vincent Lefevre wrote: > > > > > For double-double (IBM long double), I don't think the notion of > > > correct rounding makes much sense anyway. Actually the double-double > > > arithmetic is mainly useful for the basic operations in order to be > > > able to implement elementary functions accurately (first step in > > > Ziv's strategy, possibly a second step as well). IMHO, on such a > > > platform, if expl() (for instance) just calls exp(), this is OK. > > Why would that be OK? If we have higher precision long double then the libm should deliver that higher precision. > > expl just calling exp - losing 53 bits of precision - seems rather > > extreme. But I'd think it would be fine to say: when asked to compute > > f(x), take x' within 10ulp of x, and return a number within 10ulp of > > f(x'), where ulp is interpreted as if the mantissa were a fixed 106 bits > > (fewer bits for subnormals, of course). (And as a consequence, accurate > > range reduction for large arguments would be considered not to matter for > > IBM long double; sin and cos could return any value in the range [-1, 1] > > for sufficiently large arguments.) > > After thinking about this, you could assume that you have a 106-bit > floating-point system (BTW, LDBL_MANT_DIG = 106) and use the same > method to generate code that provides an accurate implementation > (if the code generator doesn't assume an IEEE 754 compatible FP > system). Concerning sin and cos, I think there should be a minimum > of specification and some consistency (such as sin(x)² + cos(x)² > being close to 1). > actually back in 2007 I overrode slowexp and slowpow for powerpc/power4 (and later) to use expl, powl on the slow path of exp/pow, instead of the mpa.h implementation. This provide a nice performance improvement but does imply some rounding mode issues.
Re: The state of glibc libm
On Mon, 2012-03-26 at 12:26 +0200, Vincent Lefevre wrote: > On 2012-03-22 16:29:00 +, Joseph S. Myers wrote: > > On Thu, 22 Mar 2012, Vincent Lefevre wrote: > > > For the same reason, if the user chose long double instead of > > > double, this may be because he wanted more precision than double. > > > > You mean range? IBM long double provides more precision, but not more > > range. > > Well, precision and/or range. If double precision format is sufficient > for his application, the user can just choose the "double" type. So, > I don't think that it is useful to have long double = double. > > Then concerning double-double vs quad (binary128) for the "long double" > type, I think that quad would be more useful, in particular because > it has been standardized and it is a true FP format. If need be (for > efficiency reasons), double-double could still be implemented using > the "double" type, via a library or ad-hoc code (that does something > more clever, taking the context into account). And the same code (with > just a change of the base type) could be reused to get a double-quad > (i.e. quad + quad) arithmetic, that can be useful to implement the > "long double" versions of the math functions (expl, and so on). > This is much easier said then done. In practice it is a major ABI change and would have to be staged over multiple (7-10) years. > > > So, in the long term, the ABI should probably be changed to have > > > long double = quadruple precision (binary128). > > > > The ABI for Power Architecture changed away from quad precision to using > > IBM long double (the original SysV ABI for PowerPC used quad precision, > > the current ABI uses IBM long double) > > Perhaps they could change back to quad precision. > That is not the feedback we get from our customers. No one will use software IEEE binary128 and we don't have hardware binary128. So far there is abstract interest but no strong demand for this. So there is no incentive to change.
