Re: On disable_cost

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, <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> > On Wed, Dec 11, 2019 at 7:24 PM Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)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
>
>
>