Hi, On Fri, Jun 12, 2020 at 4:25 AM Tom Lane <t...@sss.pgh.pa.us> wrote:
> =?UTF-8?Q?Darafei_=22Kom=D1=8Fpa=22_Praliaskouski?= <m...@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: https://github.com/postgres/postgres/blame/8fecd4febf8357f3cc20383ed29ced484877d5ac/src/backend/utils/adt/float.c#L525 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 > 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. https://en.wikipedia.org/wiki/IEEE_754#Exception_handling 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
