[Numpy-discussion] matrix indexing question

[Robert Kern]

Alan G Isaac wrote:
>>>  On Tue, 27 Mar 2007, Robert Kern apparently wrote: 
>>>>  Gram-Schmidt orthogonalization 
>  
>> Alan G Isaac wrote:
>>>  I take it from context that you consider it desirable
>>>  to end up with a list of matrices?
> 
> Robert wrote:
>> Honestly, I don't care. You asked about iteration, and 
>> I gave you an example
>> where it was important that the iterates were matrices 
>> (such that .T worked correctly).
>> Please stop moving the goal posts.
> 
> It is really not my intent to be irritating or to move the posts.
> But I had two reasons to ask.
> 
> First, your claim is false that this was important in your example.
> (To see this, replace M[1:] with M.A[1:].)
> So actually your code would work the same if iteration over 
> matrices were producing arrays
> (after replacing M[0] with M[0,:] to match that case).

You're right, it does, but only because the first place it is used, it gets
operated with the matrix row-vector base before it does anything else, gets
coerced into a matrix, and then gets assigned back to rowv. I don't tolerate
that kind of implicitness in my code.

> Second, when I spoke of *desirability*, the output is relevant.
> Try nump.mat(ortho) to see what I mean.

<shrug> If I wanted something other than a list of matrix row-vectors (which I
might), then I'd post-process. Keeping the clarity of the main algorithm is also
important.

> If iteration were to produce arrays,
> the outcome of implementing the algorithm
> (e.g., using ``dot``)
> would be I suggest more "desirable",
> in that numpy.mat(ortho) would work as hoped/expected.

Ditto for not using matrix objects at all.

> In this sense, the example perhaps speaks against your intent.
> You offer code that would work just fine if iteration 
> yielded arrays.
> 
> Apologies in advance if this again seems tangential to my 
> original request.  To me it does not.
> 
>> If you really want iterates to be arrays, just use .A.
> 
> I have mentioned that several times.
> It is orthogonal to the design issue I raised.
> (I suggested that under the current behavior you do not 
> usually end up with what you want when iterating over matrices.)
> But again, I recognize that I am alone in that view.
> I am just trying to understand why.

People have been giving you reasons, over and over again. You are simply
refusing to listen to them. You have a use case for arrays being the iterates.
You are presuming that the only argument that can beat that is another use case
for matrix objects being the iterates. This is not true; there are other
principles at work. If we were to make matrix objects behave in different ways
for different methods to satisfy what one person thinks is the most convenient
way to use each method, we would have a patchwork object with no overall
principle that people can use to understand what is going on. They would simply
have to remember which behavior someone thought was the most convenient for each
thing. Remember the lessons of rand() and randn().

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco