[PYTHON MATRIX-SIG] Final matrix object renaming and packaging

[Hinsen Konrad]

   I'm willing to be a little bit sloppy with some of the details of
   types, and force the type of a scalar argument to correspond to the
   type of the matrix.  This is essentially what I'm doing anyway when I

Does that mean that in "2.5*array([1,2,3], types.Integer)" the
prefactor will be silently cast to int? That would be a most
undesirable form of automatic type conversion.

One of the principles of operation should be that scalars are
considered as arrays of rank 0. From that it follows that they can be
cast explicitly to a rank-0 array of any type (including C-float), and
there are no more type problems.

BTW, that reminds me of another old constructor debate: should
array([1,2,3]) be a rank-1 or a rank-2 array? I still propose that
all constructors should take exactly one argument, scalar or
list, and that the rank of the array depends on the nesting of the
list. And now I have another argument for this: your current
constructors don't permit the construction of rank-0 arrays.

   No data yet on that, if you want to send me a nice simple "real"
   benchmark code for 3d vectors I'd be happy to add it to my bag of

Unfortunately that doesn't exist yet...

   tricks.  Right now everything is being optimized for LLNL style
   physics code because they sent me such a nice benchmark to run.

Which is hardly a good way to ensure the general usefulness
of a program ;-)

   I disagree here.  I find that there is a certain core of
   functions that are very nice to be able to grab with a single import
   statement.  I would hate to have to start my typical script with
   import umath, UMathMore, Matrix, Array, ArrayConstructors,
   ArrayUtilities, ...

Me too. But I'd rather write this "collection" module myself,
with everything I want in it, instead of having a standard
module that doesn't meet my needs.

   You're obviously right here.  Part of what I was hoping to do with
   this was to create a simple module so that people (even those without
   a FORTRAN compiler) could take the inverse of a matrix in a reasonable
   amount of time, and possibly to set up some sort of API, so that when
   somebody does write the ultimate linear algebra module they will be
   likely include a function called "inverse" so that I could then
   trivially plug in this new more powerful system.

We should learn a lesson from the old array module: never make an
interim solution a standard module. If we now quickly hack together
some collection of "useful" routines, then people will use this
interface and have problems later when they discover that they need
something better. Of course the implementation can always be
improved, but if we define a standard interface for anything,
it should be a good one.

For linear algebra, the best solution would probably be a module based
on LAPACK, which is free and also available in C (although the Fortran
version is more efficient on most machines). I don't know if
similar good and free packages exist for other applications, but
if we can't find out, we should leave this to other people.

-------------------------------------------------------------------------------
Konrad Hinsen                     | E-Mail: hinsenk@ere.umontreal.ca
Departement de chimie             | Tel.: +1-514-343-6111 ext. 3953
Universite de Montreal            | Fax:  +1-514-343-7586
C.P. 6128, succ. Centre-Ville     | Deutsch/Esperanto/English/Nederlands/
Montreal (QC) H3C 3J7             | Francais (phase experimentale)
-------------------------------------------------------------------------------

=================
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================