May 16, 2005 Re: Decimal Type for D? | ||||
---|---|---|---|---|
| ||||
Posted in reply to sai | "sai" <sai_member@pathlink.com> wrote in message news:d60tq8$16rq$1@digitaldaemon.com... > 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 > > > > > > Actually, it's not difficult to keep absolute precision doing decimal math in binary types, as long as you keep track of the remainders when doing division, and account for them in other calculations. For example, 1.01 * 101% = 101 / 100 * 101 /100 = (1+1/100) * (1+1/100) = (1+1/100)*1 + (1+1/100)*1/100 = 1+1/100+1/100+1/100/100 = 1 + 2/100 + 1/10000 = 1 + .02 + .0001 = 1.0201 Therefore, $1.01 * 101% = $1.02 with a remainder of one tenthousandth of $1 or a hundredth of a cent. That hundredth of a cent can be stored as a fraction until it is needed in further calculations, facilitating a partial symbolic representation of numbers and no loss of precision within the scope of decimal percentage calculations. Crude example, but I think it demonstrates the point. TZ |
May 17, 2005 Re: Decimal Type for D? | ||||
---|---|---|---|---|
| ||||
Posted in reply to TechnoZeus | "TechnoZeus" <TechnoZeus@PeoplePC.com> wrote in message news:d69l7d$1bo0$1@digitaldaemon.com... > 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. A simple solution to that problem: to get 6% of the value of n, n being in pennies: n = (n * 6) / 100; |
May 17, 2005 Re: Decimal Type for D? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | "Walter" <newshound@digitalmars.com> wrote in message news:d6bk8g$5ra$1@digitaldaemon.com... > > "TechnoZeus" <TechnoZeus@PeoplePC.com> wrote in message news:d69l7d$1bo0$1@digitaldaemon.com... > > 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. > > A simple solution to that problem: to get 6% of the value of n, n being in pennies: > > n = (n * 6) / 100; > > Yep... provided you don't mind rounding the binary results to the nearest cent. Let's try that in binary... for n=1 cent: 1 * 110 = 110; 110 / 1100100=0.00001111010111000010100011110... Okay, let's not. Hehe. Yes, it's better to do the multiplication before the devision when loss of accuracy is more of a concern than overflow, but without an infinitely large mantissa, there will always be limitations when having to use one number system to represent another. No, actually, it's not a simple solution. It's a workaround... and in general, it works. However, it's not 100% accurate. Binary math is simple, and computers tend to handle it quite well for just that reason. However, while any base 2 number of finite length can be represented as a base 10 number of finite length, the reverse is not true. Many finite length base 10 numbers require an infinite number of base 2 digits to represent precisely. A base system like base 510510 or base 9699690 in turn has the same relation to base 10 in that respect as base 10 has to base 2. In fact, base 9699690 can represent in a finite number of digits any number that can be represented in a finite number of digits in any base that is not an integer multiple of a prime number greater than 20. The down side is that calculations in such a base tend to be much less efficient on modern computers than the same calculations performed in the binary system. This is why for decades now many processors have had native support for binary coded decimal. A binary coded decimal format represents the mantissa of a number in base 10 digits, each of which are stored in a nibble (4 bits) of memory, and uses an exponent that is treated as a signed power of 10. Usually, the digits are actually hexadecimal digits with a functional range from 0 through F, but only the values 0 through 9 are needed since their place values are treated as pawers of ten. There are also cases where the digit values A through F are invalid or have special meanings, or where 3 decimal digits are packed together in a 10 bit field and treated together a single base 1000 digit (using the range of 000 through 999 out of the full 0 through 1023 binary range), with the place values of such compound digits being treated as powers of 1000. The unfortunate thing about all this, is that while base 2 representations have been standardized rather uniformly, base 10 encodings have not. Therefore, a base 10 number format that is supported directly by a microporcessor will generally tend to be platform specific. However, standards have been created, and are currently being updated and revised. Zwang is on the right track. If anyone was wondering what IEEE 754r is, check out the Wikipedia page... http://en.wikipedia.org/wiki/IEEE_754r Walter, if you're interested in information on IEEE 754r specifically for programming language developers (I'm guessing, zwang already has this link) check out... http://en.wikipedia.org/wiki/IEEE_754r/Annex_L TZ |
May 20, 2005 Re: Decimal Type for D? | ||||
---|---|---|---|---|
| ||||
Posted in reply to TechnoZeus | "TechnoZeus" <TechnoZeus@PeoplePC.com> wrote in message news:d6c02l$l28$1@digitaldaemon.com... > > "Walter" <newshound@digitalmars.com> wrote in message news:d6bk8g$5ra$1@digitaldaemon.com... > > > > "TechnoZeus" <TechnoZeus@PeoplePC.com> wrote in message news:d69l7d$1bo0$1@digitaldaemon.com... > > > 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. > > > > A simple solution to that problem: to get 6% of the value of n, n being in > > pennies: > > > > n = (n * 6) / 100; > > > > > > Yep... provided you don't mind rounding the binary results to the nearest cent. But rounding money to cents is what you want. Otherwise, you'd use floating point. And yes, I know about BCD. After all, there were special opcodes for it even in the earliest 8088! |
May 20, 2005 Re: Decimal Type for D? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | Walter wrote:
> And yes, I know about BCD. After all, there were special opcodes for it even
> in the earliest 8088!
>
>
>
And the MOS 6502/6510 :-)
|
May 21, 2005 Re: Decimal Type for D? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | "Walter" <newshound@digitalmars.com> wrote in message news:d6lmqt$1obr$1@digitaldaemon.com... > > "TechnoZeus" <TechnoZeus@PeoplePC.com> wrote in message news:d6c02l$l28$1@digitaldaemon.com... > > > > "Walter" <newshound@digitalmars.com> wrote in message > news:d6bk8g$5ra$1@digitaldaemon.com... > > > > > > "TechnoZeus" <TechnoZeus@PeoplePC.com> wrote in message news:d69l7d$1bo0$1@digitaldaemon.com... > > > > 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. > > > > > > A simple solution to that problem: to get 6% of the value of n, n being > in > > > pennies: > > > > > > n = (n * 6) / 100; > > > > > > > > > > Yep... provided you don't mind rounding the binary results to the nearest > cent. > > But rounding money to cents is what you want. Otherwise, you'd use floating point. > > And yes, I know about BCD. After all, there were special opcodes for it even in the earliest 8088! > > > Yes, you want rounding to the nearst cent... "eventually"... but doing so in every calculation can lead to an accumulated innacuracy of more than a cent... which can cause errors in transactions, which in turn can add up. That's "why" BCD exists... and why it has existed for so long. Because that type of cumulative inacuracy isn't always acceptable. TZ |
May 21, 2005 Re: Decimal Type for D? | ||||
---|---|---|---|---|
| ||||
Posted in reply to John Reimer | "John Reimer" <brk_6502@yahoo.com> wrote in message news:d6lmuf$1obs$1@digitaldaemon.com... > Walter wrote: > > > And yes, I know about BCD. After all, there were special opcodes for it even in the earliest 8088! > > > > > > > > And the MOS 6502/6510 :-) Yep. :) I wrote my first assembler on a 6502 ... using a notation that I later sent to Motorola along with the plans for the 68000 family. It was an unusual compiler, that used built in macros to simulate a more capable microprocessor with numbered data registers and flexible use of multiple addressing modes. Nice memories... what little is left of them. Hehe. TZ |
Copyright © 1999-2021 by the D Language Foundation