[PYTHON MATRIX-SIG] Type Names

[Michael McLay]

Paul. Dubois writes:
> I hold these truths to be self-evident, your argument notwithstanding:
> a. A PyFloat is a C double
>    The fact that some of the Python API lets you convert one to a C
> float easily doesn't change this.
> 
> b. It is a GOOD THING that you can count on the precision of a PyFloat.
>     Writing portable code between platforms is easy with Python, since
> even on 64 bit machines C doubles are implemented as 64 bit floats. (I
> know that isn't for certain but as a practical truth, it is true).

The idea of naming the sizes of numbers "double" and "float" in a
programming language is analogous to continuing the use the U.S. units
of measure.  If you're familiar with the units it's not a problem, but
consider the task of introducing the convention to someone new to
programming.  Why does the naming convention have to be obscure?  To
get a sense of the nonsense of this naming convention, answer the
following question.  How many gils are in a gallon?  (The first
questions you need to ask of course is whether I mean an Imperial
gallon or a U.S. gallon.)  

What do you think of the idea of explicitly naming the numeric types
to reflect the actual machine size of the number?  This would make the
size of an object perfectly clear.  It would also eliminate all future
problems with portability of numbers between machine architectures.
It won't break existing code since the old names can still be used as
aliases for the new names.  Here's all the names that would be needed.

float32
float64		(alias is float)
float128
int8
int16
int32		(alias for int)
int64
int128

The advantages are:

  1) It would make the size of a number obvious thereby eliminating
     one more source of stupid programming errors.  
  2) It would eliminate one more thing that must be learned and
     remembered by rote. 
  3) It will be easy for new users to grasp and remember the convention.

Some of the disadvantages are:

  1) It's something new.
  2) It may require introducing some new keywords.  (This probably
     isn't necessary.) 
  3) It isn't an "elegant" solution.  
  4) For individuals who already know what a float is, and who have 
     a talent for remembering minute details, the change may seem
     gratuitous.

While an "elegant", theoretical solution, such as Ada's ability to
declare types for numbers of any size, may be possible, an
implementation that allowed this would be slow for any size number
other than those supported directly in hardware.  (With the exception
of float128, the type names listed above are close to being
universally supported in modern hardware.)  Consequently, these are
probably the only numbers that will be of interest for number
crunching applications.  For problems where speed isn't as important
and more control over the calculation is needed then the application
could use an arbitrary length numbers class and add size constraints
as needed.

Isn't it time to drop a convention that was introduced when machine words
varied considerably from system to system?  

Michael

=================
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================