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.4 required=5.0 tests=BAYES_00, GUARANTEED_100_PERCENT,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,b228c96663d3035 X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Does Ada 95 conform to the IEEE 754 floating point standard? Date: 1998/02/05 Message-ID: #1/1 X-Deja-AN: 322270452 References: <6b8fdn$qrh17@beaker.nit.gwu.edu> X-Complaints-To: usenet@news.nyu.edu X-Trace: news.nyu.edu 886674545 7915 (None) 128.122.140.58 Organization: New York University Newsgroups: comp.lang.ada Date: 1998-02-05T00:00:00+00:00 List-Id: Joe said <, gwinn@res.ray.com (Joe Gwinn) wrote: >IEEE 754 is a hardware representation, handled by the computer. To access >these 32-bit single-real numbers, one must declare variables as type >"float" in ANSI C or type "FLOAT" in Ada [LRM section 3.5.7]. To access >64-bit double-real numbers, one must declare variables as type "double" in >C or type "LONG_FLOAT" in Ada [Ada LRM section 3.5.7]. >> Earlier, Joe and I had a long discussion about the importance of knowing the language as opposed to the implementation, among other things. Joe dismissed this as requiring "ada experts" ... But the above is a good example of sloppiness that comes from not making this distinction, and this kind of error can cause huge problems in porting code later on. There is absolutely NO indication, let alone a guarantee, that on an IEEE machine, float will map to IEEE short and LONG_Float to IEEE long (the same is true of ANSI C). Yes, it is a likely choice, but there have been Ada compilers, where Float was 64-bits and you had to use Short_Float to get 32 bits. In Ada 83, the best shot would be something like type IEEE_Short is digits 6; type IEEE_Long is digits 15; there is no still no requirement in Ada 83 that you will get what you want. You could however confirm that the right choices have been made using: for IEEE_Short'Size use 32; for IEEE_Long'Size use 64; but that still would not be adequate on an Alpha, where there is nothing to stop the compiler from choosing Vax Float formats in both cases (indeed DEC Ada 83 does choose Vax Float by default). In Ada 95, the problem is entirely solved by using the appropriate types in Interfaces. In any case, Joe's advice is badly flawed. To use the predefined types Float and Long_Float is really asking for trouble. Even in Ada 83, where there is no 100% guaranteed way of ensuring you get the IEEE types, the proper approach is to define types in the above manner and use them. This way, you only have to make changes at one small point in your program when you port (e.g. in DEC Ada 83, use the pragma Float_Representation). Note that this advice also applies to C. In C, there is even less control to help ensure getting the right types, but by using typedefs, you can isolate the degree of change. This kind of abstraction is absolutely essential in programming if you want to write portable code.