Re: [BUGS] BUG #2846: inconsistent and confusing handling of - Mailing list pgsql-patches

From Tom Lane
Subject Re: [BUGS] BUG #2846: inconsistent and confusing handling of
Date
Msg-id 25159.1167259456@sss.pgh.pa.us
Whole thread Raw
In response to Re: [BUGS] BUG #2846: inconsistent and confusing  (Bruce Momjian <bruce@momjian.us>)
Responses Re: [BUGS] BUG #2846: inconsistent and confusing  (Bruce Momjian <bruce@momjian.us>)
List pgsql-patches
Bruce Momjian <bruce@momjian.us> writes:
> Tom Lane wrote:
>> I think what we should probably consider is removing CheckFloat4Val
>> and CheckFloat8Val altogether, and just letting the float arithmetic
>> have its head.  Most modern hardware gets float arithmetic right per
>> spec, and we shouldn't be second-guessing it.

> Well, I am on an Xeon and can confirm that our computations of large
> non-infinite doubles who's result greatly exceed the max double are
> indeed returning infinity, as the poster reported, so something isn't
> working, if it supposed to.  What do people get for this computation?

Infinity is what you are *supposed* to get, per IEEE spec.

>> A slightly less radical proposal is to reject only the case where
>> isinf(result) and neither input isinf(); and perhaps likewise with
>> respect to NaNs.

> Uh, that's what the patch does for 'Inf':

>     result = arg1 + arg2;
>     CheckFloat4Val(result, isinf(arg1) || isinf(arg2));

No, because you are still comparing against FLOAT4_MAX.  I'm suggesting
that only an actual infinity should be rejected.  Even that is contrary
to IEEE spec, though.

The other problem with this coding technique is that it must invoke
isinf three times when the typical case really only requires one (if the
output isn't inf there is no need to perform isinf on the inputs).
If we're going to check for overflow at all, I think we should lose the
subroutine and just do

    if (isinf(result) &&
        !(isinf(arg1) || isinf(arg2)))
        ereport(...OVERFLOW...);

            regards, tom lane

pgsql-patches by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [BUGS] BUG #2846: inconsistent and confusing handling of
Next
From: Roman Kononov
Date:
Subject: Re: [BUGS] BUG #2846: inconsistent and confusing handling of underflows,