Re: Transition from 32 to 64 bit

[dewar@cs.nyu.edu (Robert Dewar)]

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 <range-actually-needed>;

    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).