From: Perry G. <pe...@st...> - 2002-03-06 20:31:09
|
Pearu writes: > > Here is one suggestion that is based on the observation that all we need > is an easy way to tell that the following operation should be applied > as a matrix operation. So, the suggestion is to provide an attribute or a > member function that returns an array (note, not a Matrix instance) that > has a bit, called it asmatrix, set true but _only_ temporally. The bit is > cleaned on every operation. And before applying an operation, the > corresponding method (currently there seem to be only four relevant > methods: __mul__, __pow__ and their r-versions) checks if either of > the operants has asmatrix bit true, then performs the corresponding matrix > operation, otherwise the default element-wise operation. And before > returning, it cleans up asmatrix bit. > > For the sake of an example, let .m be Numeric array attribute that when > accessed sets asmatrix=1 and returns the array. > Examples: > > a * b - is element-wise multiplication > a.m * b, a * b.m - are matrix multiplications, the resulting > array, as well a and b, have asmatrix=0 > a.m ** -1 - is matrix inverse > sin(a) - element-wise sin > sin(a.m) - matrix sin > > To summarize the main ideas: > * array has asmatrix bit that most of the time is false. > * there is a way to set the asmatrix bit true, either by .m or .M > attributes or .m(), .M(), .. methods that return the same array. > * __mul__, __pow__, etc. methods check if either operant has asmatrix > true, then performs the corresponding matrix operation, otherwise > the corresponding element-wise operation. > * all operations clean asmatrix bit. > > So, what do you think? > > Pearu > This is a clever idea that reminds me of something we were considering for something else (exactly what I can't quite remember :-). But like all such schemes it still does produce an object, and a user might infer (reasonably or unreasonably) that if they can type x = a.m * b Then they can treat a.m as an array, e.g., x = a.m In that case, the special case behavior still becomes camouflaged, when x is used later, albeit only to bite you once. It is clear what the operation does when the attribute is used in the expression, but if it isn't, there is still room for confusion. I like the idea, but I'll have to think about whether the downside outweighs the benefits. Perry |
From: Perry G. <pe...@st...> - 2002-03-06 20:36:58
|
Konrad Hinsen writes: > > discussed (and never resolved) a couple years ago. Suppose I do this: > > > > x = a.M * libfunc(b.M, c.M) > > > > where libfunc is a 3rd party module written in Python that was written > > assuming that operators were elementwise operators. It may silently > > Then you are calling a routine with wrong arguments - that can happen > in Python all the time. > > From my point of view, arrays and matrices are two entirely different > things. A function written for matrix objects cannot be expected to > work with array objects, and vice versa. Matrix operations should > return matrix objects, and array operations should return array > objects. > > What arrays and matrices have in common is not semantics, but > implementation. That is something that implementors should profit > from, but users shouldn't even need to know about. > > The discussion about matrices has focused on matrix multiplication as > the main difference between the two objects. I suppose this was > motivated by comparisons to Matlab and similar environments, which do > not have the notion of data types and thus cannot properly distinguish > between matrices and arrays. I don't see why should follow this > limited approach. > > A matrix object should not only do matrix multiplication properly, but > also provide methods such as diagonalization, application of functions > as matrix functions, etc. That would be much more than syntactic > sugar, it would be a real implementation of the mathematical concept > "matrix". > > Seen from this point of view, it is not at all clear why an array > should have an attribute that is an "equivalent" matrix, as no such > equivalence exists in general (only for 2D arrays). > Not an unreasonable position. Are you also arguing that the two types should know about each other and raise an exception if there is an attempt to mix them in operations? Perry |
From: Konrad H. <hi...@cn...> - 2002-03-07 08:58:54
|
"Perry Greenfield" <pe...@st...> writes: > Not an unreasonable position. Are you also arguing that the two types > should know about each other and raise an exception if there is an > attempt to mix them in operations? No need to know about each other, they'd be different types and therefore by default incompatible. There should of course be some explicit conversion facility. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hi...@cn... Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- |
From: Pearu P. <pe...@ce...> - 2002-03-06 20:49:05
|
On Wed, 6 Mar 2002, Perry Greenfield wrote: > This is a clever idea that reminds me of something we were considering > for something else (exactly what I can't quite remember :-). But like > all such schemes it still does produce an object, and a user might > infer (reasonably or unreasonably) that if they can type > > x = a.m * b > > Then they can treat a.m as an array, e.g., > > x = a.m Yes, I was also thinking about the same issue. If we could somehow confince users that .m attribute comes only with operations, e.g. a .m* b then it should be safe... Note that in order to use .m feature, an user must read about it somewhere, say, from tutorial. And there should be noted explicitely where _not_ to use .m feature, that is, in assignments and in function arguments, in order to avoid side any unwanted side effects. Actually, library functions probably use asarray for arguments, this function could also clean up the asmatrix bit. Pearu |
From: Pearu P. <pe...@ce...> - 2002-03-06 20:52:49
|
On Wed, 6 Mar 2002, Pearu Peterson wrote: > Actually, library functions probably use asarray for arguments, this > function could also clean up the asmatrix bit. Ok, ignore this remark. Library functions actually would use this bit for triggering different operations, eg. sin(a), sin(a.m). Pearu |