[Numpy-discussion] Re: [Matrix-SIG] An Experiment in code-cleanup.
Konrad Hinsen
hinsen at cnrs-orleans.fr
Tue Feb 8 13:56:21 CST 2000
> I know this will be a sticky point. I'm not sure what to do exactly, but
> the current behavior and implementation makes the semantics for slicing an
> array using a sequence problematic since I don't see a way to represent a
You are right there. But is it really necessary to extend the meaning
of slices? Of course everyone wants the functionality of indexing with
a sequence, but I'd be perfectly happy to have it implemented as a
method. Indexing would remain as it is (by reference), and a new
method would provide copying behaviour for element extraction and also
permit more generalized sequence indices.
In addition to backwards compatibility, there is another argument for
keeping indexing behaviour as it is: compatibility with other Python
sequence types. If you have a list of lists, which in many ways
behaves like a 2D array, and extract the third element (which is thus
a list), then this data is shared with the full nested list.
> > How do you plan to implement mixed arithmetic with scalars? If the
> > return value is a rank-0 array, then a single library returning
> > a rank-0 array somewhere could mess up a program well enough that
> > debugging becomes a nightmare.
> >
>
> Mixed arithmetic in general is another sticky point. I went back and read
> the discussion of this point which occured 1995-1996. It was very
What I meant was not mixed-precision arithmetic, but arithmetic in which
one operand is a scalar and the other one a rank-0 array.
Which reminds me: rank-0 arrays are also incompatible with the
nested-list view of arrays. The elements of a list of numbers are
numbers, not number-like sequence objects.
But back to precision, which is also a popular subject:
> discussion with a colleague who is starting to "get in" to Numerical
> Python and he has really been annoyed with the current mixed arithmetic
> rules. The seem to try to outguess the user. The spacesaving concept
> helps, but it still seem's like a hack to me.
I wouldn't say that the current system tries to outguess the user. It
simply gives precision a higher priority than memory space. That might
not coincide with what a particular user wants, but it is consistent
and easy to understand.
> I know there are several opinions, so I'll offer mine. We need
> simple rules that are easy to teach a newcomer. Right now the rule is
> farily simple in that coercion always proceeds up. But, mixed arithmetic
Like in Python (for scalars), C, Fortran, and all other languages that
I can think of.
> Konrad, 4 years ago, you talked about unexpected losses of precision if
> this were allowed to happen, but I couldn't understand how. To me, it is
> unexpected to have double precision arrays which are really only
> carrying single-precision results. My idea of the coercion hierchy is
I think this is a confusion of two different meanings of "precision".
In numerical algorithms, precision refers to the deviation between an
ideal and a real numerical value. In programming languages, it refers
to the *maximum* precision that can be stored in a given data type
(and is in fact often combined with a difference in range).
The upcasting rule thus ensures that
1) No precision is lost accidentally. If you multiply a float by
a double, the float might contain the exact number 2, and thus
have infinite precision. The language can't know this, so it
acts conservatively and chooses the "bigger" type.
2) No overflow occurs unless it is unavoidable (the range problem).
> The casual user will never use single precision arrays and so will not
> even notice they are there unless they request them. If they do request
There are many ways in which single-precision arrays can creep into a
program without a user's attention. Suppose you send me some data in a
pickled array, which happens to be single-precision. Or I call a
library routine that does some internal calculation on huge data
arrays, which it keeps at single precision, and (intentionally or by
error) returns a single-precision result.
I think your "active flag" solution is a rather good solution to the
casting problem, because it gives access to a different behaviour in a
very explicit way. So unless future experience points out problems,
I'd propose to keep it.
Konrad.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen at 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
-------------------------------------------------------------------------------
More information about the Numpy-discussion
mailing list