Jari-Matti Mäkelä wrote:

>>Are you volunteering to provide an import module for MAPM ? ;-)
> 
> 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.

Please do, I downloaded MAPM 4.9.2 and it worked like a charm here:
"validate : PASS"

The wrapper would probably be mapm.d and mapmextern.d, but if you've
already ported the C++ class along with the macros - the better... :-)

Rest of the m_apm.h header translated to D well enough automatically.
(with h2d.pl)


BTW:
Thanks for posting this library. Looks great, and zlib license too!
(GMP is under the LGPL, which means it must be dynamically linked)

I might upload half.d and softfloat.d somewhere later on, as well.
(for doing 16-bit, 80-bit and 128-bit floating point - in software)

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

I've never used MAPM so I'm curious about more details. When you say superior I assume you mean superior performance? What system were you using?

Ben Hinkle wrote:
>>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
> 
> 
> I've never used MAPM so I'm curious about more details. When you say superior I assume you mean superior performance? What system were you using?
> 
> 

I'm sorry, I've not yet made any extensive benchmarks. I meant that MAPM has all the necessary floating point functions integrated within the library.

AFAIK GMP only implements some primitive div/mul/add/sub and get/set-style functions. MAPM uses the FFT method when multiplying big numbers, but I think GMP uses it nowadays too. Even though GMP might be faster, it still doesn't have for example any sin, cos, ln, times, etc. functions.

I've tested the MAPM on my Gentoo Linux box with DMD and it has worked quite well. The use of huge integers isn't possible on my box with only 1,5GB of RAM. I think there is some work to do in MAPM with the error reporting system (exceptions should be used) and thread safety.


Jari-Matti

"Jari-Matti Mäkelä" <jmjmak@utu.fi.no.sp.am> wrote in message news:d5nui9$ujj$1@digitaldaemon.com...
> Ben Hinkle wrote:
>>>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
>>
>>
>> I've never used MAPM so I'm curious about more details. When you say superior I assume you mean superior performance? What system were you using?
>
> I'm sorry, I've not yet made any extensive benchmarks. I meant that MAPM has all the necessary floating point functions integrated within the library.

ok no problem. I was curious what you meant.

> AFAIK GMP only implements some primitive div/mul/add/sub and get/set-style functions. MAPM uses the FFT method when multiplying big numbers, but I think GMP uses it nowadays too. Even though GMP might be faster, it still doesn't have for example any sin, cos, ln, times, etc. functions.

Yeah - that is annoying. The mpfr routines have various special functions but it's a pity the base mpf doesn't. I suspect the gmp authors are more interested in the integer than the floating point support.

> I've tested the MAPM on my Gentoo Linux box with DMD and it has worked quite well. The use of huge integers isn't possible on my box with only 1,5GB of RAM. I think there is some work to do in MAPM with the error reporting system (exceptions should be used) and thread safety.
>
>
> Jari-Matti

"Tony" <talktotony@email.com> wrote in message news:d5m921$2n6v$2@digitaldaemon.com...
> 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?

If you use 64 bit longs to represent pennies, the max dollar amount representable would be $92,233,720,368,547,758 or 92 quadrillion dollars. Not even the federal government will overflow that anytime soon <g>.

"Walter" <newshound@digitalmars.com> wrote in message news:d5o7uu$165o$1@digitaldaemon.com...
>
> "Tony" <talktotony@email.com> wrote in message news:d5m921$2n6v$2@digitaldaemon.com...
> > 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?
>
> If you use 64 bit longs to represent pennies, the max dollar amount representable would be $92,233,720,368,547,758 or 92 quadrillion dollars. Not even the federal government will overflow that anytime soon <g>.
>

Integers are a very sub-optimal way of representing decimal values.

The May 2004 issue of Dr Dobb's Journal has an article titled: "Java & Monetary Data" which addresses some of the issues with using either integers or floating point numbers for this purpose.  The article is available online if you have a subscription.

I feel quite bad about raising this as Walter has put so much work in to D already.  A new data type is probably not something he would like to take on at this stage.  However, I do believe it is important.  For instance, I think programmers involved in e-commerce applications would consider the presence of a decimal type to be an indication that the language is trying to address their needs.

Tony
Melbourne, Australia

"Tony" <talktotony@email.com> wrote in message news:d5tgha$1cnk$1@digitaldaemon.com...
> "Walter" <newshound@digitalmars.com> wrote in message
> > If you use 64 bit longs to represent pennies, the max dollar amount representable would be $92,233,720,368,547,758 or 92 quadrillion
dollars.
> > Not even the federal government will overflow that anytime soon <g>.
> Integers are a very sub-optimal way of representing decimal values.
>
> The May 2004 issue of Dr Dobb's Journal has an article titled: "Java & Monetary Data" which addresses some of the issues with using either
integers
> or floating point numbers for this purpose.  The article is available
online
> if you have a subscription.

Would you care to summarize?

Walter wrote:
> "Tony" <talktotony@email.com> wrote in message
> news:d5m921$2n6v$2@digitaldaemon.com...
> If you use 64 bit longs to represent pennies, the max dollar amount
> representable would be $92,233,720,368,547,758 or 92 quadrillion dollars.
> Not even the federal government will overflow that anytime soon <g>.

Representing currency in pennies just isn't good enough for all financial applications. I might need to accurately keep track of tenths or hundredths of a cent.

Floating point types don't work because of accuracy problems.

Integer types don't work because my application might work with cents, and a library that I use might work with tenths-of-a-cent.

A decimal type would be able to provide the appropriate level of precision/accuracy, while remaining neutral about the number of digits on the right-hand side of the decimal point.

Of course, decimal types could be implemented easily in a library, but I think I'd rather have them in the language (or, at the very least, in the standard library).

--BenjiSmith

Walter wrote:
> "Tony" <talktotony@email.com> wrote in message
> news:d5tgha$1cnk$1@digitaldaemon.com...
> 
>>"Walter" <newshound@digitalmars.com> wrote in message
>>
>>>If you use 64 bit longs to represent pennies, the max dollar amount
>>>representable would be $92,233,720,368,547,758 or 92 quadrillion
> 
> dollars.
> 
>>>Not even the federal government will overflow that anytime soon <g>.
>>
>>Integers are a very sub-optimal way of representing decimal values.
>>
>>The May 2004 issue of Dr Dobb's Journal has an article titled: "Java &
>>Monetary Data" which addresses some of the issues with using either
> 
> integers
> 
>>or floating point numbers for this purpose.  The article is available
> 
> online
> 
>>if you have a subscription.
> 
> 
> Would you care to summarize?
> 
> 

quoted from the article:

"The use of integer data types to represent monetary values suffers from a number of significant drawbacks. Integer data types are limited in the magnitude of values that they can represent. More importantly, doing arithmetic on scaled integer values (in particular, multiplication and division) can be messy and prone to programming errors. Intermediate results must be appropriately scaled to ensure the preservation of all significant digits, and you must keep track of where the implied decimal point is located. Because of these and other issues, integer data types are not a practical choice for use with monetary data."

"Benji Smith" <dlanguage@xxagg.com> wrote in message news:d5tvu2$1ple$1@digitaldaemon.com...
> Walter wrote:
> > "Tony" <talktotony@email.com> wrote in message
> > news:d5m921$2n6v$2@digitaldaemon.com...
> > If you use 64 bit longs to represent pennies, the max dollar amount
> > representable would be $92,233,720,368,547,758 or 92 quadrillion
dollars.
> > Not even the federal government will overflow that anytime soon <g>.
>
> Representing currency in pennies just isn't good enough for all financial applications. I might need to accurately keep track of tenths or hundredths of a cent.
>
> Floating point types don't work because of accuracy problems.
>
> Integer types don't work because my application might work with cents, and a library that I use might work with tenths-of-a-cent.
>
> A decimal type would be able to provide the appropriate level of precision/accuracy, while remaining neutral about the number of digits on the right-hand side of the decimal point.
>
> Of course, decimal types could be implemented easily in a library, but I think I'd rather have them in the language (or, at the very least, in the standard library).

I obviously don't understand all the issues for such a type, so it would be difficult to design one. I suggest using a class for the time being.