Re: [PATCHES] [BUGS] BUG #2846: inconsistent and confusing handling of underflows,

2006-12-29 Thread Roman Kononov
On 12/27/2006 12:44 PM, Bruce Momjian wrote: The only unsolved issue is the one with underflow checks. I have added comments explaining the problem in case someone ever figures out how to address it. This will behave better for float4: Datum float4pl(PG_FUNCTION_ARGS) { ---float4

Re: [PATCHES] [BUGS] BUG #2846: inconsistent and confusing handling of underflows,

2006-12-27 Thread Roman Kononov
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: ~uname -a Linux rklinux 2.6.15-27-amd64-generic #1 SMP PREEMPT Fri Dec 8 17:50:54 UTC 2006

Re: [PATCHES] [BUGS] BUG #2846: inconsistent and confusing handling of underflows,

2006-12-27 Thread Roman Kononov
On 12/27/2006 04:04 PM, Bruce Momjian wrote: Interesting. I didn't know that, but in the float4pl() function, because the overflow tests and result is float4, what value is there to doing things as double --- as soon as the float4 maximum is exceeded, we throw an error? This is useful for

Re: [PATCHES] [BUGS] BUG #2846: inconsistent and confusing handling of underflows,

2006-12-27 Thread Tom Lane
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

Re: [PATCHES] [BUGS] BUG #2846: inconsistent and confusing handling of underflows,

2006-12-27 Thread Tom Lane
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)---