Fw: Re: [HACKERS] float4 regression test failed on linux parisc

2005-02-08 Thread Jim Buttafuoco
Tom,

I'm back with this issue.  I have comparied the src/backend/utils/adt/float.c 
from 7.4.6 against CVS HEAD.  There was 
some work done on the infinity handling (don't know who, I am NOT a CVS 
expert/user).  The problem I see is that the 
float4in does a check to see if the value is infinity BEFORE calling 
CheckFloat4Val (this was added for 8.0) but the 
float4div (and friends) doesn't.  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).  

I hope I have explained my problem and solution. 

Jim
-- Forwarded Message ---
From: Jim Buttafuoco [EMAIL PROTECTED]
To: Tom Lane [EMAIL PROTECTED]
Cc: pgsql-hackers pgsql-hackers@postgresql.org
Sent: Tue, 1 Feb 2005 17:20:17 -0500
Subject: Re: [HACKERS] float4 regression test failed on linux parisc 

Tom,

The issue is with a select 'Infinity'::float4/'Infinity'::float4; which should 
return NAN.  without the cast I get the 
overflow message from CheckFloat4Val with the cast I get NAN (as expected). How 
about testing for isnan() inside 
CheckFloat4Val (just for PARISC / Linux)?

I am trying to get this system working for the buildfarm as there are NO other 
HP PARISC system on the farm.

Jim

-- Original Message ---
From: Tom Lane [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: pgsql-hackers pgsql-hackers@postgresql.org
Sent: Tue, 01 Feb 2005 17:13:52 -0500
Subject: Re: [HACKERS] float4 regression test failed on linux parisc

 Jim Buttafuoco [EMAIL PROTECTED] writes:
  Change:
  CheckFloat4Val(result);
  To:
  CheckFloat4Val((float4)result);
 
 CheckFloat4Val is defined to take a double, so whatever the above is
 accomplishing is wrong: probably it's masking an out-of-range result.
 I think you've hit a bug in Debian's version of gcc for PA-RISC.
 
   regards, tom lane
--- End of Original Message ---
--- End of Forwarded Message ---


---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org


Re: [HACKERS] float4 regression test failed on linux parisc

2005-02-08 Thread Tom Lane
Jim Buttafuoco [EMAIL PROTECTED] 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 broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org


Re: [HACKERS] float4 regression test failed on linux parisc

2005-02-08 Thread Jim Buttafuoco
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 [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
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 [EMAIL PROTECTED] 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 ---


---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match


Re: [HACKERS] float4 regression test failed on linux parisc

2005-02-08 Thread Tom Lane
Jim Buttafuoco [EMAIL PROTECTED] writes:
 this test is likely to fail. I have now seen this on my real old Alpha
 and now HP PARISC systems.

It works fine on PARISC, and has ever since I've been associated with
this project --- I run these tests multiple times a day on old HP
hardware, and they have always passed with every compiler I've used
(both gcc and HP's).  Lots of people have reported clean passes on Alpha
as well.  One more time: you have a compiler bug, and you really ought
to be griping to the gcc people not us.

regards, tom lane

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly


Re: [HACKERS] float4 regression test failed on linux parisc

2005-02-08 Thread Jim Buttafuoco
except isinf() works just fine on my system.  It's just when CheckFloat4Val is 
called with infinity as the val you 
you get the overflow message.  If I move the isinf into CheckFloat4Val all is 
fine.  

If you don't want to fix this, it's fine with me.  I am just reporting problems 
and trying to fix them.  I will shut 
up now and put my energy into other causes!

Jim



-- Original Message ---
From: Tom Lane [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: pgsql-hackers pgsql-hackers@postgresql.org
Sent: Tue, 08 Feb 2005 11:42:11 -0500
Subject: Re: [HACKERS] float4 regression test failed on linux parisc 

 Jim Buttafuoco [EMAIL PROTECTED] writes:
  this test is likely to fail. I have now seen this on my real old Alpha
  and now HP PARISC systems.
 
 It works fine on PARISC, and has ever since I've been associated with
 this project --- I run these tests multiple times a day on old HP
 hardware, and they have always passed with every compiler I've used
 (both gcc and HP's).  Lots of people have reported clean passes on Alpha
 as well.  One more time: you have a compiler bug, and you really ought
 to be griping to the gcc people not us.
 
   regards, tom lane
--- End of Original Message ---


---(end of broadcast)---
TIP 8: explain analyze is your friend


[HACKERS] float4 regression test failed on linux parisc

2005-02-01 Thread Jim Buttafuoco
I am getting a float4 regression test failure.  I have extracted the SQL from 
both the float4 and float8 tests below.  
Both should return NAN

I looked at the code,  The float4div does the operation as float8's then checks 
the value.  The value is a valid 
float8 NAN.  The call to CheckFloat4Val is missing a cast back to float4.  If I 
put the cast in I get the expected 
results (NAN).


SELECT 'Infinity'::float4 / 'Infinity'::float4;
psql:test.sql:1: ERROR:  type real value out of range: overflow

SELECT 'Infinity'::float8 / 'Infinity'::float8;
 ?column? 
--
  NaN
(1 row)


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


Re: [HACKERS] float4 regression test failed on linux parisc

2005-02-01 Thread Tom Lane
Jim Buttafuoco [EMAIL PROTECTED] writes:
 I am getting a float4 regression test failure.  I have extracted the SQL from 
 both the float4 and float8 tests below.  
 Both should return NAN

 I looked at the code,  The float4div does the operation as float8's then 
 checks the value.  The value is a valid 
 float8 NAN.  The call to CheckFloat4Val is missing a cast back to float4.  If 
 I put the cast in I get the expected 
 results (NAN).

This report is about as clear as mud :-(.  What platform is this, and
what source code change are you proposing *exactly* ?

regards, tom lane

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


Re: [HACKERS] float4 regression test failed on linux parisc

2005-02-01 Thread Joshua D. Drake
Tom Lane wrote:
Jim Buttafuoco [EMAIL PROTECTED] writes:
I am getting a float4 regression test failure.  I have extracted the SQL from both the float4 and float8 tests below.  
Both should return NAN

I looked at the code,  The float4div does the operation as float8's then checks the value.  The value is a valid 
float8 NAN.  The call to CheckFloat4Val is missing a cast back to float4.  If I put the cast in I get the expected 
results (NAN).

This report is about as clear as mud :-(.  What platform is this, and
I believe the parisc platform is the HP 9000 series. Probably running 
Debian.

http://parisc-linux.org
Sincerely,
Joshua D. Drake

what source code change are you proposing *exactly* ?
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

--
Command Prompt, Inc., your source for PostgreSQL replication,
professional support, programming, managed services, shared
and dedicated hosting. Home of the Open Source Projects plPHP,
plPerlNG, pgManage,  and pgPHPtoolkit.
Contact us now at: +1-503-667-4564 - http://www.commandprompt.com
begin:vcard
fn:Joshua D. Drake
n:Drake;Joshua D.
org:Command Prompt, Inc.
adr:;;PO Box 215;Cascade Locks;Oregon;97014;USA
email;internet:[EMAIL PROTECTED]
title:Consultant
tel;work:503-667-4564
tel;fax:503-210-0334
note:Command Prompt, Inc. is the largest and oldest US based commercial PostgreSQL support provider. We  provide the only commercially viable integrated PostgreSQL replication solution, but also custom programming, and support. We authored  the book Practical PostgreSQL, the procedural language plPHP, and adding trigger capability to plPerl.
x-mozilla-html:FALSE
url:http://www.commandprompt.com/
version:2.1
end:vcard


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


Re: [HACKERS] float4 regression test failed on linux parisc

2005-02-01 Thread Jim Buttafuoco
Source: CSV HEAD (As of yesterday)
Platform: HP PARISC (HP 710)
OS: Debian Sarge
File: src/backend/utils/adt/float.c
Change:
CheckFloat4Val(result);
To:
CheckFloat4Val((float4)result);

I tested this on my parisc box and it passed all tests.  This could just be an 
issue with a very old CPU/floating 
point unit.

I can send a patch in, but since this seems to work on other platforms, I 
thought I would ask here first.

Sorry about the cryptic message, it was before my first cup of java.

Jim



Datum
float4div(PG_FUNCTION_ARGS)
{
float4  arg1 = PG_GETARG_FLOAT4(0);
float4  arg2 = PG_GETARG_FLOAT4(1);
double  result;

if (arg2 == 0.0)
ereport(ERROR,
(errcode(ERRCODE_DIVISION_BY_ZERO),
 errmsg(division by zero)));

/* Do division in float8, then check for overflow */
result = (float8) arg1 / (float8) arg2;

CheckFloat4Val(result);

PG_RETURN_FLOAT4((float4) result);
}



-- Original Message ---
From: Tom Lane [EMAIL PROTECTED]
To: Jim Buttafuoco [EMAIL PROTECTED]
Cc: pgsql-hackers pgsql-hackers@postgresql.org
Sent: Tue, 01 Feb 2005 12:06:30 -0500
Subject: Re: [HACKERS] float4 regression test failed on linux parisc 

 Jim Buttafuoco [EMAIL PROTECTED] writes:
  I am getting a float4 regression test failure.  I have extracted the SQL 
  from both the float4 and float8 tests 
below.  
  Both should return NAN
 
  I looked at the code,  The float4div does the operation as float8's then 
  checks the value.  The value is a valid 
  float8 NAN.  The call to CheckFloat4Val is missing a cast back to float4.  
  If I put the cast in I get the expected 
  results (NAN).
 
 This report is about as clear as mud :-(.  What platform is this, and
 what source code change are you proposing *exactly* ?
 
   regards, tom lane
 
 ---(end of broadcast)---
 TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
--- End of Original Message ---


---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match


Re: [HACKERS] float4 regression test failed on linux parisc

2005-02-01 Thread Tom Lane
Jim Buttafuoco [EMAIL PROTECTED] writes:
 I am trying to get this system working for the buildfarm as there are
 NO other HP PARISC system on the farm.

I still use a PA-RISC machine as my primary development environment,
so I can assure you that platform gets tested every day.  I'm not
particularly interested in catering to a broken compiler by removing
the ability to detect float4 overflow, which is what the result would be
if we use your patch.

In short: if you want this to work, I think you should file a bug with
Debian, not here.

regards, tom lane

---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match


Re: [HACKERS] float4 regression test failed on linux parisc

2005-02-01 Thread Tom Lane
Jim Buttafuoco [EMAIL PROTECTED] writes:
 Change:
 CheckFloat4Val(result);
 To:
 CheckFloat4Val((float4)result);

CheckFloat4Val is defined to take a double, so whatever the above is
accomplishing is wrong: probably it's masking an out-of-range result.
I think you've hit a bug in Debian's version of gcc for PA-RISC.

regards, tom lane

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org


Re: [HACKERS] float4 regression test failed on linux parisc

2005-02-01 Thread Jim Buttafuoco
Tom,

The issue is with a select 'Infinity'::float4/'Infinity'::float4; which should 
return NAN.  without the cast I get the 
overflow message from CheckFloat4Val with the cast I get NAN (as expected). How 
about testing for isnan() inside 
CheckFloat4Val (just for PARISC / Linux)? 

I am trying to get this system working for the buildfarm as there are NO other 
HP PARISC system on the farm.

Jim


-- Original Message ---
From: Tom Lane [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: pgsql-hackers pgsql-hackers@postgresql.org
Sent: Tue, 01 Feb 2005 17:13:52 -0500
Subject: Re: [HACKERS] float4 regression test failed on linux parisc 

 Jim Buttafuoco [EMAIL PROTECTED] writes:
  Change:
  CheckFloat4Val(result);
  To:
  CheckFloat4Val((float4)result);
 
 CheckFloat4Val is defined to take a double, so whatever the above is
 accomplishing is wrong: probably it's masking an out-of-range result.
 I think you've hit a bug in Debian's version of gcc for PA-RISC.
 
   regards, tom lane
--- End of Original Message ---


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])