From: | Jean-Christophe Pazzaglia <jc(dot)pazzaglia(at)albourne(dot)com> |
---|---|
To: | fwr(at)ga(dot)prestige(dot)net |
Cc: | "'PostgreSQL-development'" <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: The 85/0.0085 mistery ? |
Date: | 2000-10-06 14:07:45 |
Message-ID: | 39DDDCB1.4298CA38@albourne.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Frederick W. Reimer" wrote:
>
> Nothing is wrong, that's just how computers work. Fractional numbers are
> stored in a variety of formats on different platforms. Most support the
> IEEE formats, but some use their own formats. In all cases, that I'm aware
> of, the numbers are stored as a mantissa and exponent. The numbers are
> "base 2", so certain base 10 numbers don't have an exact representation in
> base 2, no matter how many bits are used in the mantissa. Other base 10
> numbers have problems with the "short" mantissa formats, but are represented
> exactly with the "long" mantissa formats.
thank you for the lesson,
I probably have done too much database this time :o
what I was really affraid was the BUT clause ...
> > jctest=> select * from eigthyfive where (cs/csbytenthousand=10000);
> > cs | csbytenthousand | csbyhundred
> > ----+-----------------+-------------
> > 88 | 0.0088 | 0.88
> > 86 | 0.0086 | 0.86
> > 84 | 0.0084 | 0.84
> > (3 rows)
> >
> > *** oh oh 85 disappeared ! ***
> >
> > BUT
> >
> > jctest=> select (85/0.0085=10000);
> > ?column?
> > ----------
> > t
> > (1 row)
... It seems that this is due to the single precision
(float4) instead of double precision (float)
(and even with a test done in base 3 :P)
BTW there is no round(float4) function
thanks
jc
Attachment | Content-Type | Size |
---|---|---|
jc.pazzaglia.vcf | text/x-vcard | 399 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Cameron Laird | 2000-10-06 14:20:41 | Ned Lilly available for questioning |
Previous Message | Frederick W. Reimer | 2000-10-06 12:47:23 | RE: The 85/0.0085 mistery ? |