[PYTHON MATRIX-SIG] Let's get going

[Jim Fulton, U.S. Geological Survey]

On Wed, 13 Sep 1995 17:30:21 -0400 
Hinsen Konrad said:
> 
>    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.

I didn't say it was a silly question. I know that lists behave this
way, but making matrices behave this way complicates things alot.

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

You have to have some reference semantics to make m[i][j] work.  
Actuall, the proposal has reference semantics for reference (ie
__getitem__) and copy semantics for element/slice assignment
(__setitem__). 
 
>    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.

I agree that we should try to focus on requirements, however, a very
basic requirement of this type is it's ability to support interfacing
with existing numerical routines, which imposes some significant
restrictions on it's implementation.

Jim

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

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