Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Bart Newsgroups: comp.lang.c Subject: Re: Can this program be improved? Date: Fri, 31 Dec 2021 02:20:07 +0000 Organization: A noiseless patient Spider Lines: 58 Message-ID: References: <87sfub2g2t.fsf@nosuchdomain.example.com> <87o84z2bsi.fsf@nosuchdomain.example.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Fri, 31 Dec 2021 02:20:07 -0000 (UTC) Injection-Info: reader02.eternal-september.org; posting-host="3d610b23c0fb246f77e5703432a94dc7"; logging-data="3562"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+7jT6ClIX4BoSv75s38yEM90AIlBUrjVA=" User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Cancel-Lock: sha1:BB0j+Aul96HPvasVWYS4kyhP++o= In-Reply-To: Xref: csiph.com comp.lang.c:164138 On 30/12/2021 17:16, Manfred wrote: > On 12/30/2021 2:06 AM, Bart wrote: >> On 30/12/2021 00:09, Keith Thompson wrote: >>> Bart writes: >> >>>> Real-world doesn't need to mean dealing with trillions of dollars to >>>> the exact cent. >>> >>> But it can mean dealing with thousands of dollars to the exact cent -- >>> and if you get a result of $1234.565001 and round it to $1234.57, when >>> the rules call for a result of $1234.56, that could be a serious >>> problem. >> >> With floating point, that result could as easily be just under >> 1234.565 as just over. If the requirements really are that binary >> floating point must have exactly identical results, down to the least >> significant bit, even for intermediates so that rounding will always >> give the same results too, then that's what you have to do. > > Yes, and that's why standard floating point is not suitable for accurate > accounting. > > IEEE 754 floating point types are designed for applications where its is > OK to assume that all values are approximated, e.g. measurements of > physical quantities. In this kind of environment the goal is to have > lots of decimal digits and huge scale of representation, some > predictable estimate of the propagation of rounding errors, and > calculation efficiency. > The price of not being able to represent exactly the value 1% (i.e. > 0.01) is acceptable, even if this value is so common, as long as the > goals above are achieved. > > The financial world has different requirements: they want exact results > whenever possible, and rounding errors, when impossible to avoid, are > thoroughly regulated. > This is because balancing the books down to the exact cent is important > to those guys. > In order to achieve this, they are willing to pay some price in terms of > representable numbers: the whole world uses monetary amounts quantified > down to the cent (2 decimal digits). In a similar fashion, conversion > ratios like currency exchange rates are conventionally expressed in a > fixed amount of significant digits (I think it's 6 or 7 digits), and the > same is likely to hold for interest rates as well. There's some upper > limit to the largest monetary amount to handle (e.g. the global wealth), > and so on. > Finally, calculations need not be super fast: a monetary transaction > involves much less computation than, say, modeling a magnetic field. > > All in all, it's no surprise that the financial world uses different > data types than floating point, like e.g. the Decimal type. Well, I have my own unlimited precision decimal floating point library. But I would still think it a vast overkill for the mortgage calculation exercise of the OP's. It also doesn't magically solve all issues. You'd have problems with exactly representing 1/3 of 1% for example, or 1/3 of £1 (approx 33.33p or exactly 6/8d in old money), or doing any similar kind of division.