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=-1.3 required=5.0 tests=BAYES_00,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: 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 X-Google-Thread: 106c43,dad65365cb2b3396 X-Google-Attributes: gid106c43,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: The disturbing myth of Eiffel portability Date: 1996/11/21 Message-ID: #1/1 X-Deja-AN: 197842158 references: <3294e64b.74799475@news2.ibm.net> <56t1m4$nis@bcrkh13.bnr.ca> organization: New York University newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.c,comp.lang.c++,comp.lang.object Date: 1996-11-21T00:00:00+00:00 List-Id: Keith said "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." No, that's wrong. the IEEE 754 and 854 standards (that is what we are referring to when we informally talk of IEEE arithmetic), require that a programmer not only have control over the rounding mode, but that this control must be *dynamic*, i.e. that a given section of code must be able to be executed with different rounding modes. Any so called IEEE arithmetic implementation that does not meet this requirement is non-standard. In practice, everyone operates in round-to-nearest all the time, I have never encountered an IEEE compliant or even semi-compliant system in which this was not the default. One thing to remember about the IEEE standard is that it is NOT a hardware standard. Generally any implementation of the standard involves a combination of software and hardware. When chip manufacturers say they provide IEEE arithmetic, they do NOT mean that any language operating on that chip is automatically IEEE standard conforming, instead they mean that their base arithmetic more or less matches the IEEE model (sometimes less than more, recently there have been some disturbing departures from the IEEE model, e.g. the failure to provide denormals on the MIPS R10000). Ada 95 as defined out of the box is nowhere near IEEE compliant. For example it lacks handling of infinities and NaN's. But it is indeed the case that Ada 95 has been designed to be compatible with the standard, in the sense that it is quite possible to provide an IEEE compliant implementation without violating Ada 95 semantics (which were carefully designed to make sure that was the case). I did a draft of a proposed IEEE binding for Ada 95 some time ago, and one of my students, Sam Figueroa, has been following up on this and refining the draft, as well as investigating some fundamental issues revolving around floating-point semantics in languages like Ada. However, there has been insufficient interest for this work to be finished so far