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.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,5c884986b9e56484 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-09-22 15:09:14 PST Path: bga.com!news.sprintlink.net!howland.reston.ans.net!europa.eng.gtefsd.com!MathWorks.Com!panix!cmcl2!thecourier.cims.nyu.edu!thecourier.cims.nyu.edu!nobody From: dewar@cs.nyu.edu (Robert Dewar) Newsgroups: comp.lang.ada Subject: Re: Transition from 32 to 64 bit Date: 22 Sep 1994 10:06:03 -0400 Organization: Courant Institute of Mathematical Sciences Message-ID: <35s30b$5vp@gnat.cs.nyu.edu> References: <1994Sep20.160716.25347@relay.nswc.navy.mil> <35n81h$1fb2@watnews1.watson.ibm.com> NNTP-Posting-Host: gnat.cs.nyu.edu Date: 1994-09-22T10:06:03-04:00 List-Id: I don't often disagree with Norm, but I don't like his use of Float_6 and Float_15. This is reminsent of the PL/1 style in which 32 bit integers were hard coded into all programs in the name of portability. If you choose to define your own types, then PLEASE don't just pick up the hardware parameters of the machine you are on, because that decreases portability rather than increases it. If you have done a careful analysis that 6 and 15 digis of precision are indeed exactly what you need, then fine, but I BET that you have not made such an analysis. In fact, better advice would be to name the two types Single and DOuble, and define them as new Short_Float and new Long_Float respectively. This will lead to the right choices on pretty much all machines, and you canm easily change them if you are on a nasty compiler that does not follow the relevant uniformity recommendation (that short should be single precision, long, double precision, and Float itself chosen as the more efficient of these two formats). The trouble with 6 and 15 is that it causes trouble on some machines. For example, suppose your compiler provides only 6 and 14. Then you will have to perform a very careful analysis of whether you can run at all on that machine, because with Norm's approach you imply that you have carefully analyzed things and determined that 15 is the minimum precision available. If that's the case, fine, if not, please don't pretend! Similarly, suppose your compiler provides 6, 14 and a special very slow software format with digits 64. Do you really want to imply that you demand the digits 64 type because the digits 14 type is inadeqaute. This business of using supposedly portable features to build in non-portability is common. Consider: type x is range -2**31 .. +2**31-1; Such type declarations are not uncommon, and are the frequent product of people who are deathly afraid of using type Integer directly. When I read such a type declaration I very much doubt that this is really the requird range, instead I am almost sure that it is merely copied from the hardware. But I don't know for sure. Consequently when I try to port that application to a 32 bit ones complement implementation (or an implementation, like the old rational machines, that used the largest negative number as an undefined value), I don't know whether I can safely adjust the low bound by 1. The proper solution for integer is to use the actual range your application requires. Sometimes this generates rafts of junk software checks, so in that case, the nice solution is: type hidden_type_not_used is ; type actual_type_to_use is range hidden_type_not_used'first .. hidden_type_not_used'last; In Ada, you can use the Base attribute to write this neatly. Oops, I should have written 'base'last and 'base'first in the above example, and what I meant in Ada 9X is that you can use type actual_type_to_use is new hidden_type_not_used'base which is a little neater. These give you a type that has the range you need but the range is increased to the next efficient hardware type. Incidentally, the use of Integer is not necessarily inappropriate if when you write Integer you mean (some efficient type suitable for indexing arrays, and I am quite willing to be limited by whatever the machine provides for efficient array indexing).