Re: behavior of arrays

[Mark Fardal <fardal(at)weka.phast.umass.edu>]

Pavel wrote
> Therefore, seems to me that FLTARR(10, 1) is the same as FLTARR(10) to
> begin with (unlike FLTARR(1, 10))...  In the example below, I see no
> loss of information in the transition from d to c...

"The difference between the right word and the almost right word is really
a large matter.  It is the difference between the lightning-bug and the
lightning."  - Twain

The difference between the right array and the almost right array is
unfortunately also a large matter.  You may think that no information
is being lost by dropping the final dimension, but the dimensionality
of the array is itself information.  This can mess up matrix
multiplications.  Herr Bauer says it can also mess up writing to a
netCDF file.  Who knows where else it could matter.

For a concrete example of the first problem, a couple months ago 
I posted a way to make CURVEFIT crash.  All you have to do is make
a single-parameter fit and mix the type (float/double) of the parameters
in a particular way.  So this problem is biting RSI's own programmers,
not just morons like me.

This behavior occurs in part because type promotion routines sometimes
(not always) change the dimensionality of the promoted variable, and
it's awfully hard to anticipate all the situations where a type
promotion could occur.  Consider what would happen if the behavior was
reversed, and REFORM sometimes decided to change the type as well as
the dimensionality of a variable.  Would that be okay too?  After all,
every integer can be represented as a float...

cheers,
Mark Fardal
UMass