Re: exp() versus the POSIX standard - Mailing list pgsql-hackers
| From | Darafei "Komяpa" Praliaskouski |
|---|---|
| Subject | Re: exp() versus the POSIX standard |
| Date | |
| Msg-id | CAC8Q8t+XJH68WB+sKN0BV0uGc3ZjA2DtbQuoJ5EhB4JAcS0C+Q@mail.gmail.com Whole thread Raw |
| In response to | Re: exp() versus the POSIX standard (Tom Lane <tgl@sss.pgh.pa.us>) |
| Responses |
Re: exp() versus the POSIX standard
|
| List | pgsql-hackers |
Hi,
On Fri, Jun 12, 2020 at 4:25 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Darafei "Komяpa" Praliaskouski <me@komzpa.net> writes:
> I've had the same issue with multiplying two tiny numbers. Select
> 2e-300::float * 2e-300::float gives an underflow, and it is not a wanted
> thing. This looks like handmade implementation of IEEE754's underflow
> exception that should be an optional return flag in addition to well
> defined number, but became a stop-the-world exception instead.
Solving that problem is very far outside the scope of what I'm interested
in here.
They're essentially the same issue.
Generally, it exists from the very beginning of git and seems to be a series of misunderstandings.
Initially, somewhere around 1996, someone thought that a double goes only from DBL_MIN to DBL_MAX, just like INT_MIN and INT_MAX, while they aren't exactly that:
That logic seems to be sane in float4 case (where computation is done in 64bit and then checked to fit into 32bit without an overflow).
It feels like the float8 case got there just by copy-paste, but maybe it was also used to not handle NaNs - it's not there in cmp's yett.
Later in 2007 Bruce Momjian removed the limitation on Infinities, but kept the general structure - now subnormals are accepted, as DBL_MIN is no longer used, but there is still a check that underflow occurred.
https://github.com/postgres/postgres/commit/f9ac414c35ea084ff70c564ab2c32adb06d5296f#diff-7068290137a01263be83308699042f1fR58
https://github.com/postgres/postgres/commit/f9ac414c35ea084ff70c564ab2c32adb06d5296f#diff-7068290137a01263be83308699042f1fR58
I think that we'd probably regret it if we try to support IEEE
subnormals, for example --- I know that all modern hardware is probably
good with those, but I'd bet against different platforms' libc functions
all behaving the same.
You don't need to support them. You just have them already.
I don't see a sane way to offer user control over
whether we throw underflow errors or not, either.
IEEE754 talks about CPU design. "Exception" there is not a postgres exception, that's an exceptional case in computation that may raise a flag.
For all those exceptional cases there is a well defined description of what value should be returned.
Current code looks like a misreading of what IEEE754 exception is, but upon closer look it looks like a mutation of misunderstanding of what FLT_MIN is for (FLT_TRUE_MIN that would fit there appeared only in C11 unfortunately).
(Do you really want "+" to stop being immutable?)
No, no kind of GUC switch is needed. Just drop underflow/overflow checks. You'll get 0 or Infinity in expected places, and infinities are okay since 2007.
The darker corners of IEEE754, like inexactness
exceptions, are even less likely to be implemented consistently
everywhere.
regards, tom lane
Darafei Praliaskouski
Support me: http://patreon.com/komzpa
pgsql-hackers by date: