www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Decimal Integer Type

reply Lawrence Dol <lawrence.dol businesslink.com> writes:
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?
Jan 23 2008
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Lawrence Dol Wrote:

 Has any consideration ever been given to support a native type
 for decimal numbers,


I think they can be useful, but inside the std lib, not "native".

Bye,
bearophile
Jan 23 2008
parent reply Lawrence Dol <lawrence.dol businesslink.com> writes:
bearophile Wrote:


 Lawrence Dol Wrote:

 Has any consideration ever been given to support a native type
 for decimal numbers,


 
 I think they can be useful, but inside the std lib, not "native".
 
 Bye,
 bearophile


"Native" was a bad choice of words; I meant built into D, like int, long, etc.
Jan 23 2008
parent bearophile <bearophileHUGS lycos.com> writes:
Lawrence Dol:

 "Native" was a bad choice of words; I meant built into D, like int, long, etc.


int, long, are built-in in the language. But I think what you ask for is better
in the std lib (and if present it must follow IEEE 854 exactly).
Note that Python has such module (written in C) in the std lib:
http://docs.python.org/lib/module-decimal.html

Bye,
bearophile
Jan 24 2008
prev sibling parent "Joel C. Salomon" <joelcsalomon gmail.com> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lawrence Dol wrote:

 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).


... As in the decimal floating-point formats in the revised IEEE 754?


 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.


The 754r decimal formats have support for recording the precision of a
number.

Actually David Hough posted this to the numeric-interest mailing list a
few days ago:

 Another draft, 1.6.0, of the IEEE 754R spec has been prepared for
 review.
 Persons who wish to comment may obtain a review copy from Bob Davis,
 bob scsi.com
 Comments are due to Bob before Feb 2.
 Review comments from end-user technical application programmers is
 especially needed, since they are the nominal target audience.
 Hardware implementers are already well represented.

 My overview, ballot, and specific comments are at
 http://754r.ucbtest.org/msc-ballots/ballot5.html
 I revise my comments from time to time as I study the draft and
 reflect on comments by other reviewers.


Comments by language implementors is probably also apropos.

- --Joel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHmjvGzLx4GzBL9dYRAjY4AKC1jQU+vpLQWOUjBKlyslZm5rdxTACfRk49
DAio4rgLhMnBjxBeesi0yZM=
=ltJk
-----END PGP SIGNATURE-----
Jan 25 2008