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/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 4: Have you searched our list archives?
http://archives.postgresql.org
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))
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
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
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
15 matches
Mail list logo
