Re: unsafe floats

From: Neil Conway <neilc(at)samurai(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Dennis Bjorklund <db(at)zigo(dot)dhs(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: unsafe floats
Date: 2004-03-10 22:36:35
Message-ID: 87ad2os51o.fsf@mailbox.samurai.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Nowadays, IEEE float math is nearly universal, and we would be
> offering better functionality if we allowed access to Infinity and
> Nan by default.

This is faulty reasoning: we *do* allow NaN by default (although
you're correct that we reject Infinity in float8 input, but it seems
not by design).

> So I'd vote for ripping out the range check, or at least reversing
> the default state of UNSAFE_FLOATS.

This would surely be wrong. Defining UNSAFE_FLOATS will make
float4in() not check that its input fits into a 'float', rather than a
'double'.

> We might end up with two sets of regression expected files, one for
> machines that do not support NaN, but that seems acceptable to me.

Are there any modern machines that actually do not support NAN? There
are various places in the code that do

#ifndef NAN
#define NAN (0.0/0.0)
#endif

... and this hasn't caused any problems that I'm aware of.

-Neil

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2004-03-10 22:36:51 Re: selective statement logging
Previous Message Neil Conway 2004-03-10 22:21:14 Re: unsafe floats