ufuncs, iterators

[S V N Vishwanathan]

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?