From: Paul K. <pv...@pv...> - 2013-04-21 17:31:54
|
Nikodemus Siivola wrote: > On 20 Apr 2013 23:43, "Anton Kovalenko"<an...@sw...> wrote: >> Except LONG-FLOAT-EPSION, that is documented to be constant but has to >> vary if the floating point precision varies. (That's what we see in >> CLISP: LONG-FLOAT-EPSION changes when you > > Presumably the same holds for other fp constants as well (most-positive... > etc)? > > This is one of the reasons I wonder if it might be better to implement long > floats as regular CMUCL-style 128 bit floats and variable/infinite > precision as an extension using the potential number syntax. (Which would > also be a neat opportunity to open NUMBER for subclassing, which in turn > would open door for supporting units... but that is neither here or now, I > guess.) IIUC, rtoym didn't implement quad floats as much as double doubles: they're not "just" floats with 128 bits of significand+exponent+sign, but rather unevaluated (and normalised) sums of two 64 bit doubles. The advantage is that double doubles are easy to implement fairly efficiently on top of hardware double floats. The problem is that they're not exactly like IEEE floats. For one, the exponent range is that for doubles, rather than the one recommended for 128 bit floats. More fundamentally, the precision of the significand varies: in the worst case, we have a sum that covers only 106 bits of precision, but it can go almost arbitrarily high (since any two doubles can be "added" without any loss of precision). That means that there is no universally correct value for long-float-epsilon if long floats are implemented as double doubles. In short, double doubles can't really respect the standard either. Paul Khuong |