Hi. I think we should do it. It shouldn't be hard. I think a lot of the discussion got bogged down on discussions about rewriting internal data structures, but these should probably be separate considerations. We should just create an immutable object based on what we currently have, and then if we work on new internal structures, build them to work with both.
Regarding your branch, I think the class hierarchy should probably be done differently. It doesn't make sense to me to make ImmutableMatrix derive from (mutable) Matrix. Then the immutable subclass has to make sure that it correctly makes all mutable implementations from the superclass immutable. What I would do is create a MatrixBase class that has all the algorithms that are independent of mutability. The subclasses Matrix and ImmutableMatrix should then contain only those things that are different between the two, like __new__ or __setitem__. That's just the first thing that comes to my mind when thinking about how I would do the class structure. Maybe others can suggest even better ways to do it. I also am wondering why you derive it from MatrixExpr. What exactly did you plan to do with that? Aaron Meurer On Sat, Jan 21, 2012 at 5:32 PM, Matthew Rocklin <mrock...@gmail.com> wrote: > Hi Everyone, > > So a question on this thread got me thinking about matrices again. > > There has been a lot of conversation in the past about the Matrix object not > being Basic. The problem is as follows: > > Most SymPy objects inherit from Basic and most SymPy functions only work on > Basics. Basic objects can not change, they must be immutable. Matrices > should be able to change, otherwise every time you say X[1,2] = 5 you need > to create a new large object and this would be slow. Thus, matrices are > placed outside of the normal SymPy family of expressions and functions. It > is a challenge to incorporate them into the rest of the work that we do. > > A possible solution to this problem is to have two Matrix types, Matrix and > ImmutableMatrix. An ImmutableMatrix is just like Matrix but its values can > not be changed, i.e. X[1,2] = 5 raises an exception. There are many > questions about how we should organize matrices to minimize code reuse, > allow for other general types of matrices, etc.... This is a complex problem > with many potential solutions. > > I've written a small example showing what I think is the minimum work > solution. I don't think this is the best solution overall but I think this > is the most likely to get into SymPy in the near future. How do people feel > about a sub-optimal near-term solution? > > My code is here > https://github.com/mrocklin/sympy/commits/immutable_matrix > > The example isn't complete but it shows the route I'm proposing. > > -matt > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To post to this group, send email to sympy@googlegroups.com. > To unsubscribe from this group, send email to > sympy+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/sympy?hl=en. -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
