Discussion: new operators for numerical computation

[Huaiyu Zhu]

On 26 Jul 2000 11:18:25 +0200, Konrad Hinsen <hinsen at cnrs-orleans.fr> wrote:
>
>With the ongoing rework of NumPy that turns arrays into Python classes
>with an underlying C implementation, it would be possible to have an
>"array" and a "matrix" class with different semantics, but sharing
>most of the code and having equal performance. Conversion between the
>two would also be possible at basically no cost, and C modules could
>be written to accept both.

The conversion between MatPy matrix and NumPy array is already quite easy,
even though MatPy currently interact with the C code only through NumPy.

I have an idea for the new NumPy development that I've put forward to
Travis. It may take more effort up front, but it would give greater instant
grtification to developers, thereby attracting more of them.  It is this:

Write the planned numpy2 as a wrapper class over existing numpy, just as
matpy is doing right now.  This wrapper class would be a working model that
defines the future multiarray interface.  This shouldn't be difficult
because it would be largely one-liners with docstrings.

Once this is done, we can substitute the underlying implementation with the
new C code "under the hood", one piece at a time.

The advantages are:
1. There is already something working, so any new code can be easily verified.
2. The developers would have a far better idea of what the future look like.
3. More developers could join because the tasks are in smaller chunks.
4. The design of interface is decoupled from the design of implementation.

>Having two different classes with different semantics is perfectly
>normal in Python. It would only be a problem if there were important
>application domains that require both semantics mixed together, but I
>am not aware of such domains.

This is why I'd prefer retaining the current situation where NumPy and MatPy
assigning oposite meaning to * as elementwise or matrix multiplication.  The
new operators would not cause any inconvenience to existing users.  They
only provide some syntactic sugar to rid NumPy of matrixmultiply(a,b) and
MatPy of a.__dotmul__(b).  Indeed they are needed where both operations are
intermixed.  I've encountered them quite often.  For example, the main
operation maybe linear algebra, but the matrices are assembled by
elementwise operations.

Huaiyu