Decimal Integer Type

Lawrence Dol lawrence.dol at businesslink.com
Wed Jan 23 13:24:32 PST 2008


Has any consideration ever been given to support a native type for decimal numbers, like Java's BigDecimal, and IBM's packed decimal type without the accuracy limitations of typical floating point representations.  This would be such that the value 1.3 would be exactly and precisely 1.3 and not actually 1.29999999999999999999 (recurring to precision limit).

I imagine 32, 64 and 128 bit values where the top bit is the sign (with no 2's compliment), and the next n bits (say 3, or maybe 7) are the decimal exponent (number of places to shift the decimal left), 3 bits allowing for 7 decimal places which would work practically for all practical business needs.

Thus, 1.3 might be 0x0100000D and -1.3 might be 0x8100000D.

32 bits having a range of -16,777,215 to 16,777,215 with up to 7 decimal places, 64 bits having a range of -72,057,594,037,927,935 to 72,057,594,037,927,935 with up to 7 decimal places, and 128 bits, perhaps allowing 7 bits for exponent, having a range of -1.3292279957849159E36 to 1.3292279957849159E36 with up to 127 decimal places.

Because the type knows how many decimal places are represented, doing a=1.10 and b=1.1234, yields for c=a+b a result of c==1.2234.

Perhaps the declaration might utilize decimal(n) where n is the number of decimals (rounding expected on overflow so decimal(2) a=1.339 yeilds a==1.34).

Am I the only one who is bitter about having to maintain currency amounts in "cents" and convert 123 to 1.23 for output??

What say you all?



More information about the Digitalmars-d mailing list