Tom Lane <[EMAIL PROTECTED]> writes:
> That sounds okay. Also we might want to distinguish NaN from
> Infinity --- I would expect most people to want zero-divide to
> continue to get reported, for instance, even if they want to get
> Infinity for overflow.
Yeah, good point.
> This I disagree wit
Neil Conway <[EMAIL PROTECTED]> writes:
> Okay, I think this would be a reasonable set of behavior:
> - define a new GUC var that controls how exceptional floating
> point values (NaN, inf, -inf) are handled.
> - by default, we still raise an error when a floating point
> oper
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> On Thu, 11 Mar 2004, Neil Conway wrote:
>> So, what is the correct behavior: if you multiply two values and get a
>> result that exceeds the range of a float8, should you get
>> 'Infinity'/'-Infinity', or an overflow error?
> That's the issue and I th
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> In C one can set a signal handler to catch floating point exceptions
> (SIGFPE). Without a handler you can get NaN and Infinity as the
> result of mathematical operations.
Okay, I think this would be a reasonable set of behavior:
- define a new G
On Thu, 11 Mar 2004, Neil Conway wrote:
> Fair enough. Attached is a patch that implements this. I chose to
> remove UNSAFE_FLOATS: if anyone thinks that is worth keeping, speak up
> now.
I have one question about the use of HUGE_VAL in postgresql. I got the
impression that the whole thing was de
On Thu, 11 Mar 2004, Neil Conway wrote:
> So, what is the correct behavior: if you multiply two values and get a
> result that exceeds the range of a float8, should you get
> 'Infinity'/'-Infinity', or an overflow error?
That's the issue and I think we should allow infinity as a result of a
floa
Neil Conway <[EMAIL PROTECTED]> writes:
> What number would you like 'Infinity'::float4 and 'Infinity'::float8
> to produce? Is this actually useful functionality?
On an IEEE-spec machine, it's highly useful functionality. +Infinity
and -Infinity are special values.
BTW the float4out and float8o
Neil Conway <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> 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
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 wr
Tom Lane <[EMAIL PROTECTED]> 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 fl
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> When UNSAFE_FLOATS is defined there is a check that float results
> are within the min and max limits, which excludes values like
> 'Infinity', '-Infinity' and 'Nan'.
No, 'NaN' is legal float4/float8/numeric input whether UNSAFE_FLOATS
is defined or n
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> When UNSAFE_FLOATS is defined there is a check that float results are
> within the min and max limits, which excludes values like 'Infinity',
> '-Infinity' and 'Nan'.
> Is the above something from the SQL standard or just a bug?
I think it was prob
12 matches
Mail list logo
