Bruce Momjian wrote:

Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
This is *not* going in the right direction :-(
Well, then show me what direction you think is better.
Fewer restrictions, not more.  The thrust of what I've been saying
(and I think Roman too) is to trust in the hardware float-arithmetic
implementation to be right.  Every time you add an additional "error
check" you are going in the wrong direction.

OK, are you saying that there is a signal we are ignoring for
overflow/underflow, or that we should just silently overflow/underflow
and not throw an error?

My understanding is that you have to actually set flags in the floating point environment to make overflows, underflows, infinities, NaNs, etc. raise signals. You might take a look at fenv.h (defined in the C99 spec) for the functions to do this. My apologies if I'm recovering well trod ground here.

Note that taking a signal on an FP exception is a horribly expensive proposition- we're talking about hundreds or thousands of clock cycles here. But it's probably worthwhile vr.s the cost of testing every floating point result, as generally FP exceptions will be rare (probably even more rare in database work than in general). So it's probably worthwhile.


Reply via email to