How PostgreSQL's floating-point hurts everyone everywhere
От | Peter Eisentraut |
---|---|
Тема | How PostgreSQL's floating-point hurts everyone everywhere |
Дата | |
Msg-id | Pine.LNX.4.21.0007201544330.640-100000@localhost.localdomain обсуждение исходный текст |
Ответы |
Re: How PostgreSQL's floating-point hurts everyone everywhere
|
Список | 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@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
В списке pgsql-hackers по дате отправления: