[long and fussy] But what do these operators _mean_?

[Huaiyu Zhu]

On 21 Jul 2000 01:33:36 GMT, Edward Jason Riedy <ejr at lotus.CS.Berkeley.EDU>
wrote: 
>Quick summary:  Maybe there needs to be a numerics-sig before any 
>of these changes are adopted...

Yes.

>And Huaiyu Zhu writes:
> - 
> -    (4) Similarity with Matlab (but not really compatibility). 
>
>Take care here.  Matlab has made many arbitrary choices that kill
>consistency.  Their treatment of 1x1 `matrices' has been discussed
>to death in the NA-digest.  And the lack of algorithm specification
>for matrix /, \, etc. has caused more than a few surprises.

This is a good one.  In MatPy 1x1 matrix is different from a scalar.

>
> -    Notation: To avoid confusion, I'll adopt matlab notation and invent 
> -    a set of unique names in the following discussions:
>
>I'll trade all the fuss over notation for fuss over _definitions_.
>I'm accustomed to using xGEMM, xGESVX, etc. in any language.  Why
>those rather than whatever the language throws at me?  They're
>well-defined.  I know their error bounds and behavior in the face 
>of floating-point oddities.  Give me those definitions, and I'll 
>take almost any notation.  Hell, I've been putting up with the
>BLAS and LAPACK naming scheme.

Concerning the semantics of these operators, I think we only need a general
agreement, leaving out algorithmic specifications to various packages.  The
advantage of Python over Matlab really shows here: Only the association
between .* and __dotmul__ would be built into the language.  The association
between __dotmul__ and the actual implementation is handled by the classes
that define __dotmul__.  Whichever package you import you'll know its
complete specification.  The advantage is that this allows natural migration
towards better algorithms without breaking any existing code.  (Cf the
migration from regex to re.)

>Before anyone adds new notations for operations, you need to be 
>sure you have definitions for those operations.  And good definitions
>will exacerbate some of the numeric issues in Python.  For example,

Imho, the only possible resolution on this is to only provide pure math
definition of these operators in the core language, leaving numerical
specification to the packages that implement them.  No one could prove that
any of the numerical algorithms used today would be optimal forever, anyway.

>Python doesn't provide reasonable ways to test for Inf or NaN.  These
>are needed in new eigenvalue routines (the only known optimal ones).
>Yes, I know, there are some non-IEEE architectures left, but they
>shouldn't be encouraged.  (Keep in mind that I'm at Berkeley; expect 
>a strong IEEE-754 bias.)

Agreed.  Although this is not the topic here, it is really a big drag. How
do Octave handle this on all platforms?  I support the idea that Python
should use IEEE whenever possible, as I don't buy Java's philosophy of using
the common minimum of every platform.

Would a NonIEEEError be possible?  That might help users on those platforms
to invoke their own error handling routines by catching this exception.

[snip.  Good links to various specifications. ]

> -    - How to deal with left division?
>
>How to compute it?  Iterative or direct?  With what pivoting 
>strategy if direct, or preconditioning if iterative?  For which 
>matrix sizes?  What about symmetric matrices?  Treating them as 
>unsymmetric adds a _lot_ of error.

I suppose that for any matrix class there could be many subclasses, such as
symmetric matrix, triangular matrix, sparse, symmetric sparse, etc.  For
each of them the methods could be overridden to use the optimal algorithm
for that specific type.  Once the general framework is settled, users
needing special cases would be able to contribute implementations without
fearing collisions with others.  Unlike matlab that is not object oriented,
in python such selections of implementation can be dealt with by special
classes instead of special methods.

For really precision or efficiency critical applications, I think nothing
beats special subclass where the user can fine tune the definition of every
methods.

>There's the possibility of Python being _better_ than Matlab, Octave, 
>SciLab, etc. and not just being equal to them.

Complete agreement here.  

Huaiyu