## digitalmars.D - Decimal Integer Type

• Lawrence Dol (8/8) Jan 23 2008 Has any consideration ever been given to support a native type for decim...
• bearophile (4/6) Jan 23 2008 I think they can be useful, but inside the std lib, not "native".
• Lawrence Dol (2/10) Jan 23 2008 "Native" was a bad choice of words; I meant built into D, like int, long...
• bearophile (6/7) Jan 24 2008 int, long, are built-in in the language. But I think what you ask for is...
• Joel C. Salomon (17/31) Jan 25 2008 -----BEGIN PGP SIGNED MESSAGE-----
```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
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
```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
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
"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