Dumping long double
Eric S. Raymond
esr at thyrsus.com
Sun Nov 5 00:48:23 UTC 2017
Hal Murray <hmurray at megapathdsl.net>:
>
> > Dropping long double opened a can of worms about overflow/precision problems
> > and how to redo the pivot logic that I didn't want to broach while were
> > trying to avoid destabilizing changes.
>
> We ran for years without long doubles. There were no destabilizing problems.
No, but changing the code *back* before 1.0 was a thing I didn't want to do.
> long double isn't cleanly supported by c. I'm amazed that wasn't enough for
> you to reject using it.
I didn't actually know that before this came up. Yes, I should have.
I rememenber now thinking that long double was a net gain, if imperfectly,
because on systems with full long double support it would address the overflow
issue, while leaving us no worse off than before elsewhere.
> The potential problem is loss of precision. The problem is converting an
> offset from l_fp to double. A l_fp is sign plus 63 bits. A double is only
> 53 bits. But most of the time, the high bits in a l_fp are 0 so they don't
> use any bits after conversion to float/double.
>
> The potential interesting case is the first long jump at startup. If all 63
> bits are interesting, we drop the bottom 10 bits when converting to a double.
> That leaves over 20 bits of fraction which is good to better than a
> microsecond.
The long double change was a response to an issue Gary brought up about the
loss of precision. Gary, what is your recommendation?
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
More information about the devel
mailing list