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.
Brian
