[PYTHON MATRIX-SIG] Let's get going

[Hinsen Konrad]

   2) Should I be able to say fft(A) where fft is an in-place FFT routine?   
   Should it be expected to modify the memory referred to by A, or only to  
   return a brand-new matrix which corresponds to the fft of A?

   I'm not sure what the right answer to this one is.

Both operations are useful in different contexts, so why not
have both? One possibility would be to have a function fft(A) that
returns a new array, and a method a.fft() to do an in-place
FFT. Implementationally the function would just copy A and call
the method. The same applies to inversion, factorization etc.
It would be nice to have some consistency here - always functions
for copies, always methods for in-place modifications.

   > I'm not sure what you mean by this.  Surely, you aren't trying to
   > make:
   >
   >    m=[[1,2,3],[4,5,6],[7,8,9]]
   >    b=[11,22,33]
   >    m=[1]=b
   >    b[1]=99
   >
   > cause m[1][1] to equal 99? Are you?

Actually this is not such a silly question, because Python's lists
behave exactly in this way. So the question is whether we want
arrays to have reference semantice (like Python lists) or value
semantics (like Python integers, floats, and complex numbers).
I strongly recommend the latter - reference semantics for
arrays quickly produce confusion, as I had to find out while
playing with such an implementation in Smalltalk.

   on, whereas operations like concatenation return a new object.  In that  
   vein, I feel that m.byteswap() should operate in-place on m and cause the  
   memory associated with m to be byte-swapped.  This is as opposed to having  
   it return a new matrix in with the same dimensions as m, but with all values  
   byte-swapped.

This depends on what you would use byte swapping for. In fact, I am
not at all convinced of its utility. What would happen when such
a byte-swapped matrix is accessed? Would all operations on it
still be allowed? That would create an enormous implementation effort.
If not, then a byte-swapped matrix would no longer be a matrix,
because none of the matrix operations could be used on it.
The only reason I can see for a byte swapping operation is during
I/O, so that's where it should go (as a flag to I/O functions).


In general, I have the impression that we get too much lost in
implementational details. Let's first define arrays as an abstract
data type in terms of the operations allowed on it from a
user's point of view and *then* worry about implementational
details.


-------------------------------------------------------------------------------
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. A                | 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
=================