Bruce Momjian wrote:<br /><blockquote cite="mid200612291512.kBTFCVY02214@momjian.us" type="cite"><pre wrap="">Tom Lane
wrote:</pre><blockquote type="cite"><pre wrap="">Bruce Momjian <a class="moz-txt-link-rfc2396E"
href="mailto:bruce@momjian.us"><bruce@momjian.us></a>writes: </pre><blockquote type="cite"><pre wrap="">Tom
Lanewrote: </pre><blockquote type="cite"><pre wrap="">This is *not* going in the right direction :-(
</pre></blockquote></blockquote><blockquotetype="cite"><pre wrap="">Well, then show me what direction you think is
better. </pre></blockquote><pre wrap="">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. </pre></blockquote><pre wrap="">
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?
</pre></blockquote> 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)
forthe functions to do this. My apologies if I'm recovering well trod ground here.<br /><br /> Note that taking a
signalon 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
willbe rare (probably even more rare in database work than in general). So it's probably worthwhile.<br /><br />
Brian<br/><br />