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.1 required=5.0 tests=BAYES_05,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,dad65365cb2b3396 X-Google-Attributes: gid109fba,public X-Google-Thread: 106c43,dad65365cb2b3396 X-Google-Attributes: gid106c43,public X-Google-Thread: 1014db,dad65365cb2b3396 X-Google-Attributes: gid1014db,public X-Google-Thread: fac41,dad65365cb2b3396 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,dad65365cb2b3396 X-Google-Attributes: gid103376,public From: kaz@vision.crest.nt.com (Kaz Kylheku) Subject: Re: The disturbing myth of Eiffel portability Date: 1996/11/19 Message-ID: <56t1m4$nis@bcrkh13.bnr.ca>#1/1 X-Deja-AN: 197486925 references: <3294e64b.74799475@news2.ibm.net> organization: Prism Systems Inc. newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.c,comp.lang.c++,comp.lang.object Date: 1996-11-19T00:00:00+00:00 List-Id: In article <3294e64b.74799475@news2.ibm.net>, The Rt Rev'd Colin James III, KOTM 1/96 wrote: >It is common knowledge that the same ANSI C source code when compiled by >different ANSI C compilers produces executables which when run yield >different, inconsistent floating point results. > >This is due to the fact that the runtime floating point packages of ANSI C >compilers vary as to word size and are not required to conform to strict Runtime packages? Most floating point code these days translates to floating point machine language. The industry is converging on using the standard IEEE floating point formats. >standards, other than weasel words, as are Ada compilers. > >Eiffel emits ANSI C code. > >Therefore Eiffel is in fact not truly portable and can in fact yield >different numerical results according to platform. 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. You cannot expect bit for bit equality from portable floating point code, but you can write the program in such a way that it will produce well-behaved approximations, and so that it will produce better and better approximations on more and more capable numerical processors. The fact is that forcing each implementation of a language to do floating point math precisely the same way is completey impractical, because it would impose a *huge* performance hit which is often not acceptable in number crunching. >That begs the following question: how can the largest Eiffel project of >over 700,000 lines of code (the CALfp bank's derivatives' program) expect >to be taken seriously if the source code when compiled on different >platforms could produce inconsistent and erroneous results. What fool would use floating point numbers for a banking system in the first place? Floating point numbers are not well suited for representing currency, except if their extra mantissa bits allow you to use them as ``large integers''. >In other words, the reason that banks generally have learned to avoid C due >to floating point problems is not solved at all but rather propagated and >worsened by the questionable strategic decision to adopt Eiffel. That fact >may of course explain why no other famous banks with both US _and_ European >computer operations have jumped on the Eiffel bandwagon and predictably >would not, such as the perfect example of CitiCorp which had the first GE >bank computers about 1962. > >Don Knuth tried to get around the floating point problem in the 1960's by >suggesting in Volumes 1 and 2 of his opus to use scaled integers. It's too >bad that the immature project weenies choose not to read that classic >anymore these days and thus don't know the meaning of integer math. So what is your real beef? That floating point code is not portable bit for bit or that it is inappropriately used by ``immature project weenies''?