Re: [HACKERS] Re: Trouble with float4 afterupgrading from 6.5.3 to 7.0.2 - Mailing list pgsql-general
From | Philip Warner |
---|---|
Subject | Re: [HACKERS] Re: Trouble with float4 afterupgrading from 6.5.3 to 7.0.2 |
Date | |
Msg-id | 3.0.5.32.20000808133755.02419100@mail.rhyme.com.au Whole thread Raw |
In response to | Re: [HACKERS] Re: Trouble with float4 afterupgrading from 6.5.3 to 7.0.2 (Tom Lane <tgl@sss.pgh.pa.us>) |
List | pgsql-general |
At 12:53 7/08/00 -0400, Tom Lane wrote: >Philip Warner <pjw@rhyme.com.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 |/
pgsql-general by date: