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?

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

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.

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

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