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: 109fba,dad65365cb2b3396 X-Google-Attributes: gid109fba,public X-Google-Thread: fac41,dad65365cb2b3396 X-Google-Attributes: gidfac41,public X-Google-Thread: 106c43,dad65365cb2b3396 X-Google-Attributes: gid106c43,public X-Google-Thread: 103376,dad65365cb2b3396 X-Google-Attributes: gid103376,public X-Google-Thread: 1014db,dad65365cb2b3396 X-Google-Attributes: gid1014db,public From: "Norman H. Cohen" Subject: Re: The disturbing myth of Eiffel portability Date: 1996/11/22 Message-ID: <3295C2D7.536B@watson.ibm.com>#1/1 X-Deja-AN: 198085589 references: <3294e64b.74799475@news2.ibm.net> <56t1m4$nis@bcrkh13.bnr.ca> content-type: text/plain; charset=us-ascii organization: IBM Thomas J. Watson Research Center mime-version: 1.0 reply-to: ncohen@watson.ibm.com newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.c,comp.lang.c++,comp.lang.object x-mailer: Mozilla 3.0 (Win95; I) Date: 1996-11-22T00:00:00+00:00 List-Id: Keith Thompson wrote: > Any bets on whether Ada 200Y mandates (or at least strongly encourages) > IEEE arithmetic? Ada 95 already explicitly acknowledges the IEEE standard (referring to it as IEC 559:1989 rather than IEEE 754, since Ada 95 is itself an ISO/IEC standard). The attribute S'Signed_Zeros is defined in A.5.3(13) in terms of the floating-point standard. A.10.9(35) gives implementation permission for floating-point Put and Get to have some textual representation of NaNs and infinities. In the Numerics Annex, G.1.1(56,57) gives advice in implementing complex arithmetic in a manner that will produce the expected results in "systems that, in the future, support an Ada binding to IEC559:1989". Of course the intent here is to allow rather than require support of IEEE arithmetic. I think implementors can be counted on to provide IEEE-based floating-point types (at the very least, types whose behavior is consistent with SOME specified IEEE mode) on those targets with IEEE-compliant hardware. Perhaps a complete binding to the full floating-point standard (with control over rounding modes and NaN signaling modes) will be adopted as a secondary standard, implementable either directly in hardware or by software emulation, depending on the target. This need not await Ada 200Y (a project that so far exists only in the imaginations of some participants in this newsgroup). > FIJAGDWOL I don't follow. Could you please elaborate? -- Norman H. Cohen mailto:ncohen@watson.ibm.com http://www.research.ibm.com/people/n/ncohen