From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Darafei "Komяpa" Praliaskouski <me(at)komzpa(dot)net> |
Cc: | PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: exp() versus the POSIX standard |
Date: | 2020-06-12 01:25:41 |
Message-ID: | 607042.1591925141@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
=?UTF-8?Q?Darafei_=22Kom=D1=8Fpa=22_Praliaskouski?= <me(at)komzpa(dot)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. 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. I don't see a sane way to offer user control over
whether we throw underflow errors or not, either. (Do you really want "+"
to stop being immutable?) The darker corners of IEEE754, like inexactness
exceptions, are even less likely to be implemented consistently
everywhere.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2020-06-12 02:28:51 | Re: Transactions involving multiple postgres foreign servers, take 2 |
Previous Message | Ranier Vilela | 2020-06-12 01:20:09 | Re: [PATCH] fix two shadow vars (src/backend/commands/sequence.c) |