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
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
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
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 fenv.h).
regards, tom lane
---(end of
On 12/29/2006 11:27 AM, Tom Lane wrote:
Doesn't even compile here (no fenv.h).
Where do you compile?
Roman
---(end of broadcast)---
TIP 6: explain analyze is your friend
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 case
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)
isinf(val))
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:
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
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
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
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
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 PREEMPT Fri
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
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
respect
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
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
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)---
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
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 FLOAT8_MAX
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,
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 platform- and
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 and
23 matches
Mail list logo
