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@sss.pgh.pa.us>
To: jim@contactbda.com
Cc: "pgsql-hackers" <pgsql-hackers@postgresql.org>
Sent: Tue, 08 Feb 2005 10:25:26 -0500
Subject: Re: [HACKERS] float4 regression test failed on linux parisc 

> "Jim Buttafuoco" <jim@contactbda.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 -------