Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Toy code for currency handling Date: Wed, 29 Nov 2017 11:31:02 -0800 Organization: None to speak of Lines: 75 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="fd1e1c2ac75c01ecf8d3296b6b1ba920"; logging-data="5143"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19JuJyEcMo7qtM/74SHhWDF" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:jwckXO2NfsIy+Arruo3i3al4eww= sha1:IQLInnv+Tf4dgY2wcz8XQYWyM6Y= Xref: csiph.com comp.lang.c:123620 bartc writes: > On 29/11/2017 19:03, Keith Thompson wrote: >> Noob writes: >>> On 29/11/2017 18:25, Keith Thompson wrote: >>>> If you're writing something for your own use, say to balance your >>>> checkbook, and a 1-cent error on an interest calculation isn't fatal, >>>> you probably don't need to worry about it. >>> >>> I would definitely *not* need 94 digits to balance my checkbook ;-) >> >> If you have an interest-bearing account, and an interest payment >> increases your balance by an amount very very close to 0.5 cents, >> you might need some large number of digits to determine which way >> to round. > > That might not help. Even if you have a million digits, one machine > might result in 0.4999...9999, and another 0.5000...0001, and they will > round in different ways to get 0.0 and 1.0 cents. > > A strategy needs to be used that will always yield the same result. > > Using integers won't help either (for working out interest), without > specifying exactly how such calculations are to be done. Here's an example of the rules for converting between pre-Euro nationatal currencies and Euros: ARTICLE 4; The conversion rates shall be adopted as one euro expressed in terms of each of the national currencies. They shall be adopted with six significant figures. The conversion rates themselves must not be rounded or truncated when making conversions. The conversion rates shall be used for conversions either way between the euro and the national currency units. Inverse rates derived from the conversion rates shall not be used. Monetary amounts to be converted from one national currency unit into another shall first be converted into a monetary amount expressed in the euro unit, which amount may be rounded to not less than three decimal places and shall then be converted into the other national currency unit. No alternative method of calculation may be used, unless it produces the same result. ARTICLE 5; Monetary amounts to be paid or accounted for, when a rounding takes place after a conversion into the euro unit according to article 4, shall be rounded up or down to the nearest cent, Monetary amounts to be paid or accounted for which are converted into a national currency unit shall be rounded up or down to the nearest sub-unit, or in the absence of a sub-unit to the nearest unit or according to national law or practice to a multiple or fraction of the sub-unit or unit of the national currency unit. If the application of the conversion rates gives a result which is exactly half-way, the sum shall be rounded up. http://www.sysmod.com/eurofaq.htm#ROUNDING This all appears to be specified in terms of decimal representations. The phrase "not less than three decimal places" is suprisingly ambiguous; I can imagine cases where the decision to use, say, 4 vs. 5 decimal places might yield results that differ by 1 cent. There are, as I understand it, a *lot* of written rules like this in various contexts. I think consistency of results is generally considered more important than mathematical perfection. You might need 94 or more digits, or even arbitrarily many digits, to compute a correctly rounded interest payment, but there are bound to be financial regulations in place that specify the rounding without requiring ludicrous precision. And you might get into some trouble if you do a computation using more precision than the regulations specify, if you end up with a different result. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"