May 12, 2005 Re: Decimal Type for D? | ||||
---|---|---|---|---|
| ||||
Posted in reply to zwang | "zwang" <nehzgnaw@gmail.com> wrote in message news:d5uc9e$21vb$1@digitaldaemon.com... > 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." I don't understand all the issues around a monetary data type. But the article is wrong on one important point - the scaling and keeping track of the decimal point. That would be true if you are doing fixed point math of the form 1.01*1.01, the result is 1.0201 and you have to remember to move the decimal point. But, and this is a big but, there aren't any financial calculations where you multiply a dollar times a dollar. If you are, you've "screwed up the dimensional analysis", as they say in physics. Dollars are multiplied by time, by a percent, by an interest rate, but never by another dollar. Of more interest, however, is overflow. When working with money, you really don't want the "silent, wraparound overflow" that happens with computer integer math. I read the article, and frankly I wouldn't use the guy's money class. I don't believe one can successfully do money calculations without understanding things like roundoff, precision, overflow, etc., and trying to paper over these things with a class just seems like a recipe for error. |
May 12, 2005 Re: Decimal Type for D? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | "Walter" <newshound@digitalmars.com> wrote in message news:d5ugim$253t$1@digitaldaemon.com... > > "zwang" <nehzgnaw@gmail.com> wrote in message news:d5uc9e$21vb$1@digitaldaemon.com... >> 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." > > I don't understand all the issues around a monetary data type. But the > article is wrong on one important point - the scaling and keeping track of > the decimal point. That would be true if you are doing fixed point math of > the form 1.01*1.01, the result is 1.0201 and you have to remember to move > the decimal point. But, and this is a big but, there aren't any financial > calculations where you multiply a dollar times a dollar. If you are, > you've > "screwed up the dimensional analysis", as they say in physics. Dollars are > multiplied by time, by a percent, by an interest rate, but never by > another > dollar. > > Of more interest, however, is overflow. When working with money, you > really > don't want the "silent, wraparound overflow" that happens with computer > integer math. > > I read the article, and frankly I wouldn't use the guy's money class. I > don't believe one can successfully do money calculations without > understanding things like roundoff, precision, overflow, etc., and trying > to > paper over these things with a class just seems like a recipe for error. Agreed. This made me think of one of my favorite fixed-point quantities: the "scaled point" (sp) in TeX. A scaled point is (2^-16)*1point. Knuth says 100sp is roughly the wavelength of visible light and 2^32sp is about 18 feet. So in a 32bit int TeX measures distances from the wavelength of light to 18feet - that's a decent range! I tend to agree that a fixed point integer of 64 bits and an appropriate scaling factor should be enough to track any reasonable "real world" quantitiy (except for some crazy physics student who wants to add the width of an atom to a galaxy or something). Now whether money is part of the real world is another question. |
May 12, 2005 Re: Decimal Type for D? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | I agree with you totally. I work for banks for years. The banks know how to deal with money. NO rounding, NO overflow could happen unintentionally NEVER.
Some banks has buggy systems, but as far as I know, all of them KNOW these kind of errors in monetary calculations. It's viable for them.
These posts and the article (which I was not able to read) seem only a theoretical issue with no connection to the real world.
Tamas
>Of more interest, however, is overflow. When working with money, you really don't want the "silent, wraparound overflow" that happens with computer integer math.
>
>I read the article, and frankly I wouldn't use the guy's money class. I don't believe one can successfully do money calculations without understanding things like roundoff, precision, overflow, etc., and trying to paper over these things with a class just seems like a recipe for error.
>
|
May 12, 2005 Re: Decimal Type for D? | ||||
---|---|---|---|---|
| ||||
Posted in reply to MicroWizard | On Thu, 12 May 2005 10:01:13 +0000 (UTC), MicroWizard wrote: > I agree with you totally. I work for banks for years. The banks know how to deal with money. NO rounding, NO overflow could happen unintentionally NEVER. I agree. My company's main product is a Retail Banking system and all rounding and overflows are very carefully coded and accounted for. You get rounding issues when calculating interest and loan repayment amounts. -- Derek Parnell Technical Product Manager - RBX, PBX Admerex Solutions Pty Ltd Melbourne, AUSTRALIA 12/05/2005 8:36:48 PM |
May 12, 2005 Re: Decimal Type for D? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Derek Parnell | "Derek Parnell" <dparnell@admerex.com> wrote in message news:6scaj2gqf1s3$.xj18j8wulwh6$.dlg@40tude.net... > On Thu, 12 May 2005 10:01:13 +0000 (UTC), MicroWizard wrote: > > > I agree with you totally. I work for banks for years. The banks know how to deal > > with money. NO rounding, NO overflow could happen unintentionally NEVER. > > I agree. My company's main product is a Retail Banking system and all rounding and overflows are very carefully coded and accounted for. You get rounding issues when calculating interest and loan repayment amounts. If anyone is in doubt about this, recall the story a few years ago about the bank programmer who adjusted the partial penny roundoffs to credit his personal account with the roundoff errors. Over time, this amounted to serious money ($millions), serious enough that it tripped him up. |
May 12, 2005 Re: Decimal Type for D? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | In article <d60m9n$12go$1@digitaldaemon.com>, Walter says... > > >"Derek Parnell" <dparnell@admerex.com> wrote in message news:6scaj2gqf1s3$.xj18j8wulwh6$.dlg@40tude.net... >> On Thu, 12 May 2005 10:01:13 +0000 (UTC), MicroWizard wrote: >> >> > I agree with you totally. I work for banks for years. The banks know how >to deal >> > with money. NO rounding, NO overflow could happen unintentionally NEVER. >> >> I agree. My company's main product is a Retail Banking system and all rounding and overflows are very carefully coded and accounted for. You get rounding issues when calculating interest and loan repayment amounts. When math errors quite literally cost the customer money, they want the code to be infallible. There's something about watching money literally disappear that drives accountants crazy :) In my experience, rounding error is much more of a problem with fixed decimal calculations than with floating point calculations--losing a fraction of a penny every step of the way adds up fast. I think it generally makes more sense to do floating point math and then figure out what to do with the fractional amount at the end. >If anyone is in doubt about this, recall the story a few years ago about the bank programmer who adjusted the partial penny roundoffs to credit his personal account with the roundoff errors. Over time, this amounted to serious money ($millions), serious enough that it tripped him up. FWIW, Hedge Funds typically designate a "rounding partner" that receives these fractional pennies. Someday maybe I'll do some data scraping and see what the average per-period rounding amount is for a typical partnership, but I can tell you right now that the number isn't small. Sean |
May 13, 2005 Re: Decimal Type for D? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean Kelly | I worked for a famous financial company for one year, there, surprisingly all transactions and processing of money were done using simple float type, in c++ as well as java. Rounding-off etc were taken care at the end. Just a note, the company invests millions of dollars in mutual, hedge funds etc. and makes more than 50% profit every year, atleast thats what we were told. -Sai In article <d60otv$1495$1@digitaldaemon.com>, Sean Kelly says... > >In article <d60m9n$12go$1@digitaldaemon.com>, Walter says... >> >> >>"Derek Parnell" <dparnell@admerex.com> wrote in message news:6scaj2gqf1s3$.xj18j8wulwh6$.dlg@40tude.net... >>> On Thu, 12 May 2005 10:01:13 +0000 (UTC), MicroWizard wrote: >>> >>> > I agree with you totally. I work for banks for years. The banks know how >>to deal >>> > with money. NO rounding, NO overflow could happen unintentionally NEVER. >>> >>> I agree. My company's main product is a Retail Banking system and all rounding and overflows are very carefully coded and accounted for. You get rounding issues when calculating interest and loan repayment amounts. > >When math errors quite literally cost the customer money, they want the code to be infallible. There's something about watching money literally disappear that drives accountants crazy :) In my experience, rounding error is much more of a problem with fixed decimal calculations than with floating point calculations--losing a fraction of a penny every step of the way adds up fast. I think it generally makes more sense to do floating point math and then figure out what to do with the fractional amount at the end. > >>If anyone is in doubt about this, recall the story a few years ago about the bank programmer who adjusted the partial penny roundoffs to credit his personal account with the roundoff errors. Over time, this amounted to serious money ($millions), serious enough that it tripped him up. > >FWIW, Hedge Funds typically designate a "rounding partner" that receives these fractional pennies. Someday maybe I'll do some data scraping and see what the average per-period rounding amount is for a typical partnership, but I can tell you right now that the number isn't small. > > >Sean > > |
May 13, 2005 Re: Decimal Type for D? | ||||
---|---|---|---|---|
| ||||
Posted in reply to sai | sai wrote:
> I worked for a famous financial company for one year, there, surprisingly all
> transactions and processing of money were done using simple float type, in c++
> as well as java. Rounding-off etc were taken care at the end. Just a note, the
> company invests millions of dollars in mutual, hedge funds etc. and makes more
> than 50% profit every year, atleast thats what we were told.
>
> -Sai
>
>
That's scary!!!!
|
May 16, 2005 Re: Decimal Type for D? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kevin Bealer | "Kevin Bealer" <Kevin_member@pathlink.com> wrote in message news:d5n37d$9vk$1@digitaldaemon.com... > 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 > > Actually, this concept carries over to much more than just financial applications. What you are talking about is a simple form of a symbolic type. The problem with non-symbolic type precision is simple to explain by example if you consider the case of division by 3 or 7 in base 10. A symbolic type would represent 22/7 as a fraction, while a non-symbolic decimal type would represent it as 3.14285714285714285714285714285714... and a non-symbolic binary type would represent it as 11.001001001001001... to the number of digits allowed in the mantissa. Neither of these exactly represents the quantity of 22 divided by 7 because a finite mantissa can't hold the results in the base of the given exponent. A symbolic type would represent 4/3 as a fraction, while a non-symbolic decimal type would represent it as 1.33333333333333333333333333333333... and a non-symbolic binary type would represent it as 1.0101010101010101... to the number of digits allowed in the mantissa. Again, neither of these exactly represents the quantity of 4 divided by 3 because a finite mantissa can't hold the results in the base of the given exponent. The problem representing decimal values in a binary format is that the factors of 10 are 2 and 5, while 5 is not a factor of 2. To demonstrate this, we need to try division by 5 or by an integer multiple of 5 (such as 10, 20, or 100). A symbolic type would represent 7/5 as a fraction, while a non-symbolic decimal type would represent it as 1.4 and a non-symbolic binary type would represent it as 1.0110011001100110... to the number of digits allowed in the mantissa. Notice that in this case, the decimal representation does exactly represents the quantity of 7 divided by 5 but the binary representation does not, because a finite mantissa can't hold the results of dividing an integer by a prime number which is neither a factor of that integer or nor a factor of the exponent used to scale the mantissa. Other precision losses stem from a generalization of this limitation. TZ |
May 16, 2005 Re: Decimal Type for D? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | "Walter" <newshound@digitalmars.com> wrote in message news:d5ud1h$22h9$1@digitaldaemon.com... > > "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. > > Designing a decimal type isn't really difficult at all. The only necessary stipulation is that the exponent be interpreted as an exponent of 10 rather than of 2. The real chore is in making all of the base 10 math functions to go with it. You mentioned the multiplication of 1.01 by 1.01 in another reply, but said that you could only see that happening if someone is multiplying dollar amounts by dollar amounts. Yet, you also mentioned percentages and interest rates. Interest rates are generally given in percentages, and a percentage is by definition some number divided by 100, such as 101% = 101/100 = 1.01 which in binary is roughly the binary value representet by 1.00 followed by a repeated "000010100011110101110000101000111101011100001010001111010111" taking an infinite number of mantissa digits to precisely represent in binary. In fact, the same problem exists with any percentage between (but not including) 0% and 100%, other than x% where x is an integer multiple of 25 or the product of such an integer and a negative integer power of 2. As much as I dislike the decimal number system, it is used a lot... so I agree that native support for decimal type would be good to have. Support for a symbolic type would be even better... but much harder to implement. I think a decimal type would be a reasonable compromise to consider for native support. - Just my opinion. TZ |
Copyright © 1999-2021 by the D Language Foundation