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@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
