On Tuesday, May 15, 2012, Ronan Lamy wrote:

> Le lundi 14 mai 2012 à 10:08 -0700, Vinzent Steinberg a écrit :
>
> >
> > I think we should keep the interfaces different. You have addition and
> > multiplication with scalars for a vector/matrix, but in general not
> > for a tuple. Also, you have for example transposition, which does not
> > make sense for tuples.
> >
> >
> > Maybe the implementations should share more code in order to be less
> > redundant though. I agree with Aaron, it might make sense for
> > ImmutableMatrix to subclass Tuple.
> >
> I disagree. An ImmutableMatrix is clearly not Liskov-substitutable for a
> Tuple. For Tuples, "+" means concatenation, not addition, and matrices
> are 2-D while tuples are 1-D, so indexing works differently.
>

I agree. The constructors are different too. In fact, looking at the code,
I'm doubtful whether any code is shared between the two classes at all,
except for trivial boilerplate shared by most classes.

The only concept shared between the two classes is that they are both
iterables, and this concept should be indicated by subclassing, but rather
by the definition of the __iter__ method.  Actually, even in this concept
they differ if you consider a matrix to be a column vector of row vectors,
because iteration goes through the elements, not through the row vectors as
naive iteration would do (and as iteration of a similarly constructed Tuple
would do).

So nsolve and other functions that try to apply heuristics to Tuple vs.
Matrix should treat the matrices separately if it makes sense, and
otherwise just use the duck typing to determine that the object is a
container type, or alternately not support container types at all and just
require the user to do the iteration with a list comprehension or something
similar.

Aaron Meurer


-- 
Sent from my iPad.

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Reply via email to