> > Is there a reason we can't perform the conversion and then copy the
> > low-order bits manually, with some bit-shifting and masking?
> *What* low-order bits? The fundamental problem is we don't have 'em.
OK, we represent 10.1 (decimal) with 1010.000110011..., repeating the 0011
pattern. In floating point representation, we say this is 2^3 *
1.010000110011..., repeating the 0011 pattern.
But this dosen't work very well, because when we print it out it won't be
exact, it will be some decimal number ending in a 0 or a 5. So when we
read this out in decimal, we get 10.099999995, with a variable number of
9's depending on the precision we use.
When we print this number out, we perform the decimal conversion, and then
truncate the last decimal digit and round.
So I guess the question is, why can't we perform 4-bit float -> 8-bit
float conversion via a decimal conversion, irrespective of storing the
thing in ASCII.
Mabye the decimal conversion is too costly? Perhaps we could 1) mark 4-bit
floats with a flag of some kind indicating whether or not the decimal
conversion is necessary, and 2) avoid this conversion wherever possible,
including giving people a warning when they use float4s in their tuples.
Or mabye I'm just being dumb.
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2000-08-07 00:36:11|
|Subject: Re: LIKE pattern matching |
|Previous:||From: Thomas Lockhart||Date: 2000-08-07 00:00:19|
|Subject: Re: OK to remove operators for exp() and ln()|
pgsql-general by date
|Next:||From: vectro||Date: 2000-08-07 00:06:27|
|Subject: Re: foreign keys|
|Previous:||From: vectro||Date: 2000-08-06 21:36:19|
|Subject: Re: [HACKERS] Re: Trouble with float4 afterupgrading from
6.5.3 to 7.0.2 |