Re: [HACKERS] [PATCHES] [BUGS] BUG #2846: inconsistent and confusing handling
On 12/27/2006 01:15 PM, Tom Lane wrote: I'm not convinced that you're fixing things so much as doing your best to destroy IEEE-compliant float arithmetic behavior. I think what we should probably consider is removing CheckFloat4Val and CheckFloat8Val altogether, and just letting the float arithmetic have its head. Most modern hardware gets float arithmetic right per spec, and we shouldn't be second-guessing it. I vote for complete IEEE-compliance. No exceptions with pure floating point math. Float - int conversions should reject overflow, INF and NaN. Float - numeric conversions should reject INF. A slightly less radical proposal is to reject only the case where isinf(result) and neither input isinf(); and perhaps likewise with respect to NaNs. This might look like another possibility for confusion. For example INF-INF=NaN. Regards, Roman. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [PATCHES] [BUGS] BUG #2846: inconsistent and confusing handling of
Bruce Momjian [EMAIL PROTECTED] writes: I have made some more progress on this patch. I'm not convinced that you're fixing things so much as doing your best to destroy IEEE-compliant float arithmetic behavior. I think what we should probably consider is removing CheckFloat4Val and CheckFloat8Val altogether, and just letting the float arithmetic have its head. Most modern hardware gets float arithmetic right per spec, and we shouldn't be second-guessing it. A slightly less radical proposal is to reject only the case where isinf(result) and neither input isinf(); and perhaps likewise with respect to NaNs. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] [BUGS] BUG #2846: inconsistent and confusing handling of
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: I think what we should probably consider is removing CheckFloat4Val and CheckFloat8Val altogether, and just letting the float arithmetic have its head. Most modern hardware gets float arithmetic right per spec, and we shouldn't be second-guessing it. Well, I am on an Xeon and can confirm that our computations of large non-infinite doubles who's result greatly exceed the max double are indeed returning infinity, as the poster reported, so something isn't working, if it supposed to. What do people get for this computation? Infinity is what you are *supposed* to get, per IEEE spec. A slightly less radical proposal is to reject only the case where isinf(result) and neither input isinf(); and perhaps likewise with respect to NaNs. Uh, that's what the patch does for 'Inf': result = arg1 + arg2; CheckFloat4Val(result, isinf(arg1) || isinf(arg2)); No, because you are still comparing against FLOAT4_MAX. I'm suggesting that only an actual infinity should be rejected. Even that is contrary to IEEE spec, though. The other problem with this coding technique is that it must invoke isinf three times when the typical case really only requires one (if the output isn't inf there is no need to perform isinf on the inputs). If we're going to check for overflow at all, I think we should lose the subroutine and just do if (isinf(result) !(isinf(arg1) || isinf(arg2))) ereport(...OVERFLOW...); regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [PATCHES] [BUGS] BUG #2846: inconsistent and confusing handling of underflows,
Roman Kononov [EMAIL PROTECTED] writes: On 12/27/2006 03:23 PM, Bruce Momjian wrote: Are you sure? As I remember, computation automatically upgrades to 'double'. See this program and output: This is platform- and compiler- dependent: ... and probably irrelevant, too. We should store the result into a float4 variable and then test for isinf() on that; that eliminates the question of whether the compiler did the multiply in a wider format or not. regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] [PATCHES] [BUGS] BUG #2846: inconsistent and confusing handling of underflows,
Roman Kononov [EMAIL PROTECTED] writes: In float4mul() and float4div(), the computation should be double precision. Why? It's going to have to fit in a float4 eventually anyway. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [PATCHES] [BUGS] BUG #2846: inconsistent and confusing handling
On 12/27/2006 05:19 PM, Tom Lane wrote: Roman Kononov [EMAIL PROTECTED] writes: On 12/27/2006 03:23 PM, Bruce Momjian wrote: Are you sure? As I remember, computation automatically upgrades to 'double'. See this program and output: This is platform- and compiler- dependent: ... and probably irrelevant, too. We should store the result into a float4 variable and then test for isinf() on that; that eliminates the question of whether the compiler did the multiply in a wider format or not. You are right provided that you want to ignore underflows and silently produce zeros instead. If you go this way, I recommend to ignore overflows as well, and silently produce infinities and NaNs. Roman ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
