How PostgreSQL's floating-point hurts everyone everywhere

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: How PostgreSQL's floating-point hurts everyone everywhere
Date: 2000-07-20 16:10:24
Message-ID: Pine.LNX.4.21.0007201544330.640-100000@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Forgive me for the tacky subject, but the analogies are not far-fetched.

I was just looking whether the UNSAFE_FLOATS compile-time option could
perhaps be a run-time option, but I'm getting the feeling that it
shouldn't be an option at all.

"Safe" floats check after each floating point function call whether the
result is "in bounds". This leads to interesting results such as

peter=# select 'nan'::float8;
?column?
----------
NaN
(1 row)

peter=# select 'infinity'::float8;
ERROR: Bad float8 input format -- overflow

What happened?

The "safe floats" mode checker will fail if `result > FLOAT8_MAX', which
will kick in for 'infinity' but is false for 'nan'. The carefully crafted
support for infinities is dead code.

Also:

peter=# select 1.0/0.0;
ERROR: float8div: divide by zero error

Division by zero is not an "error" in floating point arithmetic.

I think the CheckFloat{4,8}Val() functions should be abandoned and the
floating point results should be allowed to overflow to +Infinity or
underflow to -Infinity. There also need to be isinf() and isnan()
functions, because surely "x = 'infinity'" isn't going to work.

This is not a high-priority issue to me, nor do I feel particularly
qualified on the details, but at least we might agree that something's
wrong.

--
Peter Eisentraut Sernanders väg 10:115
peter_e(at)gmx(dot)net 75262 Uppsala
http://yi.org/peter-e/ Sweden

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Karel Zak 2000-07-20 16:16:15 Re: locale changes
Previous Message Justin Hickey 2000-07-20 16:06:12 Re: 8Ko limitation