Dumping long double

[Eric S. Raymond]

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.