I think this would be ready to abstract away behind a few functions that could always be replaced by something else later...
However on further thought I really think just using a 32-bit float and 32 bits of other bitmaps or counters would be a better approach. On Sun., Dec. 15, 2019, 14:54 Tom Lane, <t...@sss.pgh.pa.us> wrote: > Thomas Munro <thomas.mu...@gmail.com> writes: > > On Wed, Dec 11, 2019 at 7:24 PM Laurenz Albe <laurenz.a...@cybertec.at> > wrote: > >> Doesn't that rely on a specific implementation of double precision > (IEEE)? > >> I thought that we don't want to limit ourselves to platforms with IEEE > floats. > > > Just by the way, you might want to read the second last paragraph of > > the commit message for 02ddd499. The dream is over, we're never going > > to run on Vax. > > Still, the proposed hack is doubling down on IEEE dependency in a way > that I quite dislike, in that (a) it doesn't just read float values > but generates new ones (and assumes that the hardware/libc will react in > a predictable way to them), (b) in a part of the code that has no damn > business having close dependencies on float format, and (c) for a gain > far smaller than what we got from the Ryu code. > > We have had prior discussions about whether 02ddd499 justifies adding > more IEEE dependencies elsewhere. I don't think it does. IEEE 754 > is not the last word that will ever be said on floating-point arithmetic, > any more than x86_64 is the last CPU architecture that anyone will ever > care about. We should keep our dependencies on it well circumscribed. > > regards, tom lane > > >
