Re: [HACKERS] Re: Trouble with float4 afterupgrading from 6.5.3 to 7.0.2

From: Philip Warner <pjw(at)rhyme(dot)com(dot)au>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>, Romanenko Mikhail <mikhail(at)angg(dot)ru>, pgsql-general(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Re: Trouble with float4 afterupgrading from 6.5.3 to 7.0.2
Date: 2000-08-08 03:37:55
Message-ID: 3.0.5.32.20000808133755.02419100@mail.rhyme.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

At 12:53 7/08/00 -0400, Tom Lane wrote:
>Philip Warner <pjw(at)rhyme(dot)com(dot)au> writes:
>> Now I understand, but it doesn't quite make sense given what was displayed.
>> The float4 value is *displayed* as 10.1, not 10.1000001, so I had assumed
>> that there was a level of either accuracy or display rouding happening.
>
>I suppose we could implement the conversion as "float8in(float4out(x))"
>instead of "(double) x" but it'd be several orders of magnitude slower,
>as well as being *less* useful to those who know what they're doing with
>float math (since the result would actually be a less-precise conversion
>except in cases where the intended value has a short decimal
>representation).

Would I be right in saying that "those who know what they're doing with
float math" would totally avoid mixing float4 & float8? If so, then ISTM
that any changes to float4/8 conversions should not affect them.

There seem to be a few choices:

- go with zero-extending the bits. This is easy, and what would be expected
for normal float ops, at least by people who understand float implementations.

- do an intermediate text or numeric conversion. This will produce more
expected results, but at the expense of speed. If people complain about
speed, then they can change all float types to matching precision, or use
numeric data types.

- take the code from 'printf' or 'numeric' and do the appropriate
bit-munging to get the value to use in conversion. No idea if this would
work, but it is probably better than doing a text conversion since we won't
be at the mercy of the occasional C library that produces 10.1000001.

Would it be worth having some kind of DB setting for how it handles
float4/8 conversion? Or is it just too much work, when just using all
float8 or numeric is an acceptable workaround?

Do you know how fast 'numeric' is?

>That will just cause
>failures in other situations.

If there are genuine failures that would be introduced, then clearly it's a
bad idea. But, since it will only affect people who compare float4/8, it
doesn't seem too likely to produce worse failures than the change you have
already made. I ask this mainly out of curiosity - I assume there are more
aspects to this issue that I have missed...

Bye for now,

Philip.

----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.C.N. 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2000-08-08 03:54:52 Re: pg_dump help
Previous Message Stephan Szabo 2000-08-07 23:28:14 Re: foreign keys

Browse pgsql-hackers by date

  From Date Subject
Next Message Romanenko Mikhail 2000-08-08 03:59:49 Re: Trouble with float4 after upgrading from 6.5.3 to 7.0.2
Previous Message The Hermit Hacker 2000-08-07 23:45:42 Re: AW: LIKE/ESCAPE et al, initdb required!