-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Gregory Stark schrieb am 01.03.2007 10:23:
> "Patric Bechtel" <bechtel@ipcon.de> writes:
>
>> Maybe you want to have a look here:
>> http://www2.hursley.ibm.com/decimal/DPDecimal.html
>
> Well we're not really looking for the optimal packing in general. All the
> problems here have to do with convenience in the implementation rather than
> the problems with the approach. It's easier in the code to have fixed size
> scale and weight and to have them at the beginning of the data type,
which is
> fine for larger values but for small values they dominate and waste space.
>
> But as far as the approach goes, I admit I find it a bit hard to
believe that
> we're still doing BCD in the 21st century at all.
:D That's true in the first glance. But fact is, that, if the numbers
get bigger, it get's hard to implement certain algorithms properly while
on arbitrary format (read: decimal) these are tested and available. Not
mentioning that you would have to provide different algos for 4 byte/8
byte or weird 31bit machines.
Another reason to use bcd still is that errors (I don't mean real
errors, but imprecisions, overflow etc) occur where you expect them,
because humans in the Real World (tm) tend to use basis 10 for their
everyday numbers. And, after all, the ANSI754 imprecisions come exactly
from the unexpected occurence of roundings and internal number format
behaviour.
> If we stored the digits in base 2 with a base 10 exponent would it
really be
> too hard to output the digits? Even long multiplication and then
reversing the
> results doesn't seem like it would be too bad and surely there must exist
> reasonable algorithms to do better.
You should go with this, as it's just on-disk representation. Sorry if I
got you wrong on that, the focus of the decimal project goes more for
in-memory representation of arbitrary numbers and really calculate with
them, even implement this in hardware.
I would really welcome the above mentioned, also for big numbers, as it
would greatly decrease the amount of storage needed for huge amounts of
numerics (12 bytes for "10530" *is* somewhat unreasonable imho).
Anyway, your patch called my attention to this matter, so many thanks
already to that. Any improvement there would be really great :-) (tell
me if I can lend a hand)
Patric
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: GnuPT 2.5.2
iD4DBQFF5klnfGgGu8y7ypARAh7lAKC3mdnsx08yf91Py/DDMAlCF8hDegCWMMFG
K4kBkAGX/cUp+dk7Ch+W5Q==
=BIHo
-----END PGP SIGNATURE-----
