[Matrix-SIG] Numeric Nits

Konrad Hinsen hinsen@cnrs-orleans.fr
Wed, 23 Jun 1999 19:18:32 +0200


> First, perhaps the Numeric should be modified to so that zero-size arrays do
> not get turned to scalars when they are manipulated. So, for example,
> "-array(5)" would result in a zero sized array containing -5, not the scalar

The original design decision was that rank-0 arrays should never be
returned from any common operation because of their somewhat weird
behaviour. In principle rank-0 arrays *are* scalars, and in fact
rank-0 arrays practically behave like Python scalars, but many
routines that expect scalars will not accept rank-0 arrays. It would
be very confusing to have two kinds of data that are almost the same.

Another problem is that there is no clean way to extract a scalar from
a rank-0 array. Indexing requires a number of indices which is at most
equal to the rank, but you can't index with zero indices! In practice,
rank-0 arrays can be indexed with one index that has to be zero, but
that's a kludge rather than good design.

> negative five. I think this is feasible (at least in JNumeric where I'm
> familiar with the internals), but I haven't investigated it in depth. It's
> also possible it will break code. Something to think about anyway.

It would break tons of code; for example, any routine written in C and
expecting a number would raise an exception if it were fed a rank-0
array!

> Second, two static functions could be added to Numeric to set the precision
> of Scalar values. By default, floats would be converted to type 'd' when
> they are converted to zero-d arrays, as they are now, but a call to:
> 
> >>> Numeric.setFloatPrecision('f')
> 
> would result in floats be converted to type 'f' instead. For example:

That would create all the well-known problems of a global interpreter
status. What if you ask for single-precision and then call a subroutine
that expects double? What if you call a subroutine that changes the
precision? And what about thread-safety?

> The big advantage of this approach is it's gauranteed to not break any code.

Only if it's not used! ;-)

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hinsen@cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------