Bruce Momjian <maillist@candle.pha.pa.us> writes:
>> needs 4 cycles instead of 10 (because the decimal point has
>> the same meaning in base 10000 the last value is stored
>> internally as short ints 1, 2030, 1234, 5000). This is the
>> worst case and it still saved 60% of the innermost cycles!
> Interesting. How do other Db's do it internally? Anyone know?
Probably the same way, if they want to be portable. What Jan is
describing is a *real* standard technique (it's recommended in Knuth).
AFAIK the only other way to speed up a digit-at-a-time implementation
is to drop down to the assembly level and use packed-decimal
instructions ... if your machine has any ...
One thing worth thinking about is whether the storage format shouldn't
be made the same as the calculation format, so as to eliminate the
conversion costs. At four decimal digits per int2, it wouldn't cost
us anything to do so.
regards, tom lane
PS: BTW, Jan, if you do not have a copy of Knuth's volume 2, I'd
definitely recommend laying your hands on it for this project.
His description of multiprecision arithmetic is the best I've seen
anywhere.
If we thought that the math functions (sqrt, exp, etc) for numerics
were really getting used for anything, it might also be fun to try
to put in some better algorithms for them. I've got a copy of Cody
and Waite, which has been the bible for such things for twenty years.
But my guess is that it wouldn't be worth the trouble, except to the
extent that it speeds up the regression tests ;-)
