-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gregory Stark schrieb am 01.03.2007 10:23: > "Patric Bechtel" <[EMAIL PROTECTED]> 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----- ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend