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?
