If D aims to be a popular mainstream language, then it must address the needs of financial/commerce applications.

One of the fundamental types in this genre is the high-precision decimal type.

I noticed that Walter argued the advantages of having types built-in rather than based in libraries for complex numbers, and I assume that the argument is equally valid for a decimal type.

Are there any plans to include a built-in decimal type in D?

Tony

Tony wrote:
> If D aims to be a popular mainstream language, then it must address the
> needs of financial/commerce applications.
> 
> One of the fundamental types in this genre is the high-precision decimal
> type.
> 
> I noticed that Walter argued the advantages of having types built-in rather
> than based in libraries for complex numbers, and I assume that the argument
> is equally valid for a decimal type.
> 
> Are there any plans to include a built-in decimal type in D?
> 
> Tony
> 
> 
> 

I am writing a high-precision decimal type library for D according to
the draft of IEEE 754R.

Tony wrote:
> If D aims to be a popular mainstream language, then it must address the
> needs of financial/commerce applications.
> 
> One of the fundamental types in this genre is the high-precision decimal
> type.
> 
> I noticed that Walter argued the advantages of having types built-in rather
> than based in libraries for complex numbers, and I assume that the argument
> is equally valid for a decimal type.
> 
> Are there any plans to include a built-in decimal type in D?

D has 3 floating point types: 32-bit float, 64-bit double, and a real type that is the largest floating point size on the current hardware platform (80-bit on Intel). So, what are you looking for beyond this?

Mike Parker wrote:
> Tony wrote:
> 
>> If D aims to be a popular mainstream language, then it must address the
>> needs of financial/commerce applications.
>>
>> One of the fundamental types in this genre is the high-precision decimal
>> type.
>>
>> I noticed that Walter argued the advantages of having types built-in rather
>> than based in libraries for complex numbers, and I assume that the argument
>> is equally valid for a decimal type.
>>
>> Are there any plans to include a built-in decimal type in D?
> 
> 
> D has 3 floating point types: 32-bit float, 64-bit double, and a real type that is the largest floating point size on the current hardware platform (80-bit on Intel). So, what are you looking for beyond this?


"high-precision *decimal* type."

"zwang" <nehzgnaw@gmail.com> wrote in message news:d5me6n$2r10$1@digitaldaemon.com...
> Tony wrote:
> > If D aims to be a popular mainstream language, then it must address the needs of financial/commerce applications.
> >
> > One of the fundamental types in this genre is the high-precision decimal type.
> >
> > I noticed that Walter argued the advantages of having types built-in
rather
> > than based in libraries for complex numbers, and I assume that the
argument
> > is equally valid for a decimal type.
> >
> > Are there any plans to include a built-in decimal type in D?
> >
> > Tony
> >
> >
> >
>
> I am writing a high-precision decimal type library for D according to the draft of IEEE 754R.

Hi Zwang.

That's good news.

Is your library going to conform to a particular precision (Decimal32, Decimal64, Decimal128) or is it to be unlimited/variable precision?

Also, this is such a fundamental capability; I wonder if it could be added to Phobos?

Tony

In article <d5medn$2r8t$1@digitaldaemon.com>, Mike Parker says...
>
>Tony wrote:
>> If D aims to be a popular mainstream language, then it must address the needs of financial/commerce applications.
>> 
>> One of the fundamental types in this genre is the high-precision decimal type.
>> 
>> I noticed that Walter argued the advantages of having types built-in rather than based in libraries for complex numbers, and I assume that the argument is equally valid for a decimal type.
>> 
>> Are there any plans to include a built-in decimal type in D?
>
>D has 3 floating point types: 32-bit float, 64-bit double, and a real type that is the largest floating point size on the current hardware platform (80-bit on Intel). So, what are you looking for beyond this?

:import std.stdio;
:
:int main()
:{
:    double e1 = 0.11;
:    double e2 = 0.39;
:    double e3 = 0.5;
:
:    writefln("not equal, ", e3-(e1+e2));
:
:    return 0;
:}

I think a decimal type implies that numeric computations are done in base 10. If the above test was computed in base 10, it would display 0.

This can be important if .11, .39, and .5 are parts of a dollar.

I think a good (exchange) format for a generic number would be:

<M,B,E> == mantissa, base, exponent.

Normal floating point numbers (float, double, real) are a special case where the base is always 2.  Decimal numbers would always use a base of 10.  But you can represent other numerical idioms in the same form.

Generally <M,B,E> is M * (B^E).

double   = <M, 2,  E>  // ordinary computer arithmetic decimal  = <M, 10, E>  // decimal (usually financial) fraction = <N, D, -1>  // N/D; N=numerator, D=denominator

By doing this, all +-*/ calculations can be exact if the inputs are; if you multiply 11/13 by .001, you get something like:

<11,13,-1> * <1,10,-3> = <11,13000,-1>, ie exactly 11/13000.

In normal "double" arithmetic, each of these operations loses precision.

Of course, if you compute a fourier transform with this kind of number, it will be slow.  And if you don't use some kind of BigInts to do this, at least one of the components of the number will be in danger of overflowing.

If you don't want BigInts, you could specify a fixed size for each piece and start rounding off when the components got too big.  Three longs should do a pretty good job.

If you used 2 doubles and a long for the components, I think the results would still be exact for small values (doubles do not lose precision as long as they store integer values less than some maximum).  When the values got too large, you would get the transition to imprecise reckoning without notice or intervention.  Doubles will overflow eventually though, so some intervention is probably inevitable.

When I say "intervention" here, I mean testing for overflow conditions and rounding the number when necessary.

(For financial apps, overflow would probably want to throw an exception?)

Kevin

Mike Parker wrote:

> D has 3 floating point types: 32-bit float, 64-bit double, and a real type that is the largest floating point size on the current hardware platform (80-bit on Intel). So, what are you looking for beyond this?

By the way (regarding non-decimal floating point):

I ported the OpenEXR 16-bit "half" floating point format from C++ to D.
(Basically just for storage, it's converted to "float" for calculations)

And SoftFloat has support for 80-bit "extended" on non-Intel, and for
128-bit "quad" on all platforms. But it's slower than hardware, though.


Not sure if support for "half" and "quad" is wanted in the D language ?
But that is two (or three, with 80-bit) formats beyond what it has now.

Then again, we already have GMP - with all kinds of precisions...
http://home.comcast.net/~benhinkle/gmp-d/

--anders

Anders F Björklund wrote:
> Mike Parker wrote:
> 
>> D has 3 floating point types: 32-bit float, 64-bit double, and a real type that is the largest floating point size on the current hardware platform (80-bit on Intel). So, what are you looking for beyond this?
> 
> 
> By the way (regarding non-decimal floating point):
> 
> I ported the OpenEXR 16-bit "half" floating point format from C++ to D. (Basically just for storage, it's converted to "float" for calculations)
> 
> And SoftFloat has support for 80-bit "extended" on non-Intel, and for 128-bit "quad" on all platforms. But it's slower than hardware, though.
> 
> 
> Not sure if support for "half" and "quad" is wanted in the D language ? But that is two (or three, with 80-bit) formats beyond what it has now.
> 
> Then again, we already have GMP - with all kinds of precisions... http://home.comcast.net/~benhinkle/gmp-d/
> 
> --anders

Is there a particular reason to use GMP instead of MAPM [1]? I've used MAPM for complex matrix calculations and it seems to be superior to GMP.

[1] http://www.tc.umn.edu/~ringx004/mapm-main.html


Jari-Matti

Jari-Matti Mäkelä wrote:

>>Then again, we already have GMP - with all kinds of precisions...
>>http://home.comcast.net/~benhinkle/gmp-d/
> 
> Is there a particular reason to use GMP instead of MAPM [1]? I've used
> MAPM for complex matrix calculations and it seems to be superior to GMP.

No, just that there already was a D module for GMP available...

Are you volunteering to provide an import module for MAPM ? ;-)

--anders

Anders F Björklund wrote:
> Jari-Matti Mäkelä wrote:
> 
>>> Then again, we already have GMP - with all kinds of precisions... http://home.comcast.net/~benhinkle/gmp-d/
>>
>>
>> Is there a particular reason to use GMP instead of MAPM [1]? I've used MAPM for complex matrix calculations and it seems to be superior to GMP.
> 
> 
> No, just that there already was a D module for GMP available...
> 
> Are you volunteering to provide an import module for MAPM ? ;-)
> 
> --anders

I did a D wrapper for the MAPM two years ago, pretty similar to that C++ -wrapper that comes with MAPM. I'm not aware of any "standards" with D modules already written so it might be something terrible - has been sufficient for my use though. If anyone wants, I can get it from my old machine, test it and put it on my home page.


Jari-Matti