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 arithm
On 12/29/2006 11:27 AM, Tom Lane wrote:
Doesn't even compile here (no ).
Where do you compile?
Roman
---(end of broadcast)---
TIP 6: explain analyze is your friend
Roman Kononov <[EMAIL PROTECTED]> writes:
> Think about this idea please. This has no INF, NaN or range
> checks and detects all "bad" cases with any floating point
> math.
Doesn't even compile here (no ).
regards, tom lane
---(end of broadcast)---
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 a
On 12/29/2006 12:23 AM, Bruce Momjian wrote:
Well, then show me what direction you think is better.
Think about this idea please. This has no INF, NaN or range
checks and detects all "bad" cases with any floating point
math.
The only issue is that a bad case is detected only once.
You need to
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I wasn't excited about doing one isinf() call to avoid three, so I just
> made a fast isinf() macro:
> /*We call isinf() a lot, so we use a fast version in this file */
> #define fast_isinf(val) (((val) < DBL_MIN || (val) > DBL_MAX) &&
> i
Tom Lane wrote:
> 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 c
Roman Kononov wrote:
> 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 pl
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
Tom Lane wrote:
> 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.
One issue is in the patch comment:
!* Computations that slightly exceed FLOA
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 prob
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)--
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 stor
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 und
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'
Roman Kononov wrote:
> 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 PREE
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 x86_6
> I get 'inf'. I am on BSD and just tested it on Fedora Core 2 and got
> 'inf' too.
Ubuntu Edgy 64bit on Athlon 64X2 returns inf.
Joshua D. Drake
>
> > A slightly less radical proposal is to reject only the case where
> > isinf(result) and neither input isinf(); and perhaps likewise with
> >
Tom Lane wrote:
> 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
Roman Kononov wrote:
> 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 float4p
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 CheckFloat8
I have made some more progress on this patch. I have fixed the issue
with aggregates:
test=> select avg(ff) from tt;
ERROR: type "double precision" value out of range: overflow
and tested the performance overhead of the new CheckFloat8Val() calls
the fix requires using:
Roman Kononov wrote:
>
> The following bug has been logged online:
>
> Bug reference: 2846
> Logged by: Roman Kononov
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.2.0 and older
> Operating system: linux 2.6.15-27-amd64 ubuntu
> Description:inconsistent a
23 matches
Mail list logo
