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

From: Don Baccus <dhogaza(at)pacifier(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Philip Warner <pjw(at)rhyme(dot)com(dot)au>
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: Re: [GENERAL] Trouble with float4 afterupgrading from 6.5.3 to 7.0.2
Date: 2000-08-08 14:21:08
Message-ID: 3.0.1.32.20000808072108.0143b450@mail.pacifier.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

At 10:04 AM 8/8/00 -0400, Tom Lane wrote:
>Philip Warner <pjw(at)rhyme(dot)com(dot)au> writes:
>> Given this, I have assumed that printf etc use these least significant bits
>> to determine the 'correct' representation.
>
>No. What float4-to-text really does is *discard* information, by
>rounding off the printed result to only 7 digits (when there are
>actually 7-and-change in there).

Which is the standard approach for such conversion routines. If you
keep generating digits they're just garbage anyway.

As far as the rest, Phil, it is true that well-designed floating-point
hardware such as that which follows the IEEE spec (well, at least
better-designed compared to most of its predecessors) strictly specifies
how extra rounding information is to be used during various mathematical
operations (add, multiply, etc). This is done so that error due to rounding
can be strictly bounded. The result (for float4) is a 24-bit mantissa
with strictly defined significance.

However, the float4 itself once stored only consists of that 24-bit
mantissa. There's no way to know the history of how that 24th bit
was generated, i.e. whether all the bits to the right were exactly
zero or whether it was the result of rounding (or truncation if the
user specified it and the hardware supports it).

Kludging conversion by using decimal conversion will simply lose
significance. In your 10.1 case you'll be happy because that 24th
bit becomes zero.

All you've accomplished, though, is to throw away (at least) one bit.
Your float8 now has no more than 23 bits of significance rather than
24. Repeat this process a few times and you could store the result
in a boolean, in terms of the bits you could guarantee to be
significant ...

>I don't much care for this behavior (since it means dump and reload of
>float columns is lossy),

A good reason for binary backup programs!

> and I certainly won't hold still for
>introducing it into other operations on floats.

No, it flies in the face of not only convention, but a lot of investigation
into how to implement floating point arithmetic in a way that's useful
to those who have to depend on the results having mathematically definable
error bounds.

- Don Baccus, Portland OR <dhogaza(at)pacifier(dot)com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Steve Heaven 2000-08-08 14:36:51 Re: Query plan and sub-queries
Previous Message Mike Mascari 2000-08-08 14:17:23 Re: Query plan and sub-queries

Browse pgsql-hackers by date

  From Date Subject
Next Message Steve Heaven 2000-08-08 14:36:51 Re: Query plan and sub-queries
Previous Message Mike Mascari 2000-08-08 14:17:23 Re: Query plan and sub-queries