I withdraw my concern for the (I thought) possible mislocation of the various operations on "Matrices". So folks should feel free to begin to add them. Barry On Sat, 20 Aug 2005, S V N Vishwanathan wrote:

Hi!

Barry> After sleeping on it, it may be ok to include these methods in Barry> Mat as methods for "filling up matrices" so long as in the end Barry> you end up with a Mat that you then use as an operator.

Yes that sounds like a good test to me. If the end result of the computation is a matrix which is going to be used as a linear operator then we must include it in. That means that for instance methods like exp(M) and M.*X should also be supported. Right?

Barry> But I'd still like to see/understand a little more of the Barry> "construction" process. Classically one would do that as loops Barry> over elements and perform all the computations for the one Barry> element before moving to the next. In Matlab this can be done Barry> instead (with some impact on performance) using a sequence of Barry> array operations (with the loop inside each array operation). In Barry> the past, since PETSc was used exclusively from C/C++ and Fortran Barry> users built their matrices (operators) using the "classical" Barry> approach, now with python it appears reasonable that we may need Barry> to add the "array" approach.

Yes I think we should add both i.e. ability to loop over all elements and apply a function or to loop only over the arrays and perform operations on the arrays.

...

...

I am thinking more about what Barry said. The VecPointwise*() operations can be given a solid mathematical interpretation in terms of spinor operations. However, I do not see anything like that for the Mat stuff yet. We need to understand the mathematicas better.

Pardon my ignorance. What are spinor operations? Why isn't something like a M.*X a matrix operation. It is the Hadamard product.

vishy

----- Don't you wish that all the people who sincerely want to help you could agree with each other?