Re: [BUGS] BUG #2846: inconsistent and confusing handling of

Bruce Momjian <bruce(at)momjian(dot)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