From: | "Henry B(dot) Hotz" <hotz(at)jpl(dot)nasa(dot)gov> |
---|---|
To: | Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>, Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: How PostgreSQL's floating-point hurts everyone everywhere |
Date: | 2000-07-20 17:03:51 |
Message-ID: | v0421010ab59cdfe424c9@[137.78.84.130] |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At 4:47 PM +0000 7/20/00, Thomas Lockhart wrote:
>Typically, machines will trap overflow/underflow/NaN problems in
>floating point, but silently ignore these properties with integer
>arithmetic. It would be nice to have consistant behavior across all
>types, but I'll stick to floats for discussion now.
The IEEE standard says that that behavior must be configurable. The
standard behavior in Fortran is to ignore floating point exceptions
as well. Unfortunately the name of the C routine which changes it is
not defined in the standard.
This is a bit off-topic but we have this problem with the DS1
spacecraft software. Everything is run with the exceptions enabled
because we don't want to allow those values undetected in the
attitude control calculations. OTOH we are vulnerable to reboots
(and have had one) due to mistakes in other code.
Signature failed Preliminary Design Review.
Feasibility of a new signature is currently being evaluated.
h(dot)b(dot)hotz(at)jpl(dot)nasa(dot)gov, or hbhotz(at)oxy(dot)edu
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 2000-07-20 17:28:59 | Re: How PostgreSQL's floating-point hurts everyone everywhere |
Previous Message | Thomas Lockhart | 2000-07-20 16:47:03 | Re: How PostgreSQL's floating-point hurts everyone everywhere |