From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,dad65365cb2b3396 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,dad65365cb2b3396 X-Google-Attributes: gid103376,public X-Google-Thread: 106c43,dad65365cb2b3396 X-Google-Attributes: gid106c43,public X-Google-Thread: 109fba,dad65365cb2b3396 X-Google-Attributes: gid109fba,public X-Google-Thread: 1014db,dad65365cb2b3396 X-Google-Attributes: gid1014db,public From: fred@genesis.demon.co.uk (Lawrence Kirby) Subject: Re: The disturbing myth of Eiffel portability Date: 1996/11/24 Message-ID: <848871509snz@genesis.demon.co.uk>#1/1 X-Deja-AN: 198509223 references: <3294e64b.74799475@news2.ibm.net> <56t1m4$nis@bcrkh13.bnr.ca> x-mail2news-user: fred@genesis.demon.co.uk x-mail2news-path: genesis.demon.co.uk organization: none reply-to: fred@genesis.demon.co.uk newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.c,comp.lang.c++,comp.lang.object Date: 1996-11-24T00:00:00+00:00 List-Id: In article kst@thomsoft.com "Keith Thompson" writes: >In dewar@merv.cs.nyu.edu (Robert Dewar) writes: >> Kaz says >> >> > Any computer scientist worth his salt knows that floating point >> > numbers are only approximations of real quantities. Well written >> > numerical analysis code takes this into consideration, and can be >> > made portable. >[...] >> Many computer scientists have this view of floating-point, but at least in >> the IEEE world, this is an incorrect view. IEEE arithmetic is NOT an >> approximation of real arithmetic, but rather an EXACT implementation of >> a very well defined arithmetic, whose axioms are well understood. > >True, but that well defined arithmetic was designed to be an approximation >of real arithmetic. I observe that there are a lot of 32 bit integer + IEEE floating point platforms out there so what is the best way to implement financial calculations (being the topic of this thread) on such platforms? If you represent quantities as integral values that can be represented exactly by IEEE then you have something has a larger guaranteed range of values than a 32 bit integer (e.g. what long often in on C implementations) and results are exact so long as they too are representable. Division can be dealt with without too much difficulty. Many CPUs now can process floating point operations (especially mutiplication) faster than they can process integer operations. Financial calculations within (fairly generous) limits can use IEEE floating point and be *proven* correct barring bugs in the implementation. But bugs can affect integer calculations as well. All this depends on the type of operation being performed. Adding up the value of a portfolio has different issues compared to calculating loan repayments/compound interest. The former can be trivially done using IEEE floating point. The latter is an imprecise quantity unless you specify extra rules. Floating point is probably as good as any format in dealing with it and better than most. No format can represent general irrational quantities precisely. >> The idea that it is wrong to test for exact equality is quite incorrect, >> there are many algorithms where it is perfectly legitimate to test for >> exact equality if you know you are dealing with IEEE arithmetic. > >Agreed. It's important to remember, though, that the behavior of IEEE >arithmetic can change depending on the current rounding mode, and the >programmer may or may not have direct control over that. However, I >don't think that affects any cases where it makes sense to test for >exact equality. However in situations where all results are exact and within the precision of the format. So for a useful class of problems rounding method makes no difference. -- ----------------------------------------- Lawrence Kirby | fred@genesis.demon.co.uk Wilts, England | 70734.126@compuserve.com -----------------------------------------