Re: float4 regression test failed on linux parisc

Tom,

The other option is to note that on older ( and I mean real old systems where the fp unit is sub par) systems that
this test is likely to fail. I have now seen this on my real old Alpha and now HP PARISC systems. Is there a way to
just modify the regression test to pass by these test on these platforms?

Jim

---------- Original Message -----------
From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: jim(at)contactbda(dot)com
Cc: "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>
Sent: Tue, 08 Feb 2005 10:25:26 -0500
Subject: Re: [HACKERS] float4 regression test failed on linux parisc

> "Jim Buttafuoco" <jim(at)contactbda(dot)com> writes:
> > All I want to do is add a check in CheckFloat4Val for infinity (and remove the
> > individual checks before the CheckFloat4Val call in other routines).
>
> That's not at all what you proposed before, and it would have vastly
> more side-effects than just removing the platform-dependent behavior
> you are on about. If we did that then this would work:
>
> regression=# select ('infinity'::float4) / (1::float4);
> ERROR: type "real" value out of range: overflow
>
> ... which arguably it ought to, but you'd be changing the behavior
> everywhere not just for your broken compiler.
>
> I think the real question we ought to face up to sometime is what it is
> we are trying to accomplish with CheckFloat4Val and CheckFloat8Val in
> the first place. The latter routine in particular seems pretty
> ill-advised to me: if something can be represented as a double then why
> don't we just allow it?
>
> ISTM that what we really want is to reject out-of-range results, as in
> these examples:
>
> regression=# select (1e37::float4) / (1e-37::float4);
> ERROR: type "real" value out of range: overflow
> regression=# select (1e300::float8) / (1e-37::float8);
> ERROR: type "double precision" value out of range: overflow
> regression=#
>
> On machines that have IEEE infinity, I think it would work to report
> overflow if the result is infinity when neither input is. But I dunno
> how well that works on non-IEEE hardware. Also, what about rejecting
> NaN results? Thoughts anyone?
>
> regards, tom lane
------- End of Original Message -------