Re: unsafe floats - Mailing list pgsql-hackers

From Dennis Bjorklund
Subject Re: unsafe floats
Date
Msg-id Pine.LNX.4.44.0403102323430.13979-100000@zigo.dhs.org
Whole thread Raw
In response to Re: unsafe floats  (Neil Conway <neilc@samurai.com>)
Responses Re: unsafe floats
List pgsql-hackers
On Wed, 10 Mar 2004, Neil Conway wrote:

> No, 'NaN' is legal float4/float8/numeric input whether UNSAFE_FLOATS
> is defined or not.

Yes, the tests are:
 if (fabs(val) > FLOAT8_MAX) if (val != 0.0 && fabs(val) < FLOAT8_MIN)

and only infinity and not NaN will trigger the overflow. I read it wrong 
first.

> Well, CheckFloat4Val() is needed to ensure that the input fits in a
> 'float' (rather than just a 'double').

Sure, for Float4 (maybe working with float in C instead of double and this 
check would make a difference, but I havn't really thought about that).

> What number would you like 'Infinity'::float4 and 'Infinity'::float8
> to produce? Is this actually useful functionality?

I would like them to produce the IEEE 754 number 'infinity' (usually 
writte 'Inf' in other languages).

> As for it being in the SQL standard, using Acrobat's "text search"
> feature finds zero instances of "infinity" (case insensitive) in the
> 200x draft spec. I haven't checked any more thoroughly than that,
> though.

If they say that it should use IEEE 754 math, then they do say that
Infinity is a number, just like it is in C and lots of other languages
with IEEE 754 math. Being as old as it is, I would guess that the standard
doesn't really say much at all about floats.

Why should pg not do the same as most (all?) other language that use IEEE 
754 math?

-- 
/Dennis Björklund



pgsql-hackers by date:

Previous
From: Neil Conway
Date:
Subject: Re: unsafe floats
Next
From: Bruce Momjian
Date:
Subject: Re: selective statement logging