On Jul 12, 10:33 pm, Matthew Rocklin <mrock...@gmail.com> wrote: > I strongly support your separation of abstract external matrix interfaces > from internal matrix representations (Dense, LIL, DOK). I believe that this > makes the code much more extensible. For example this allows us to easily > create an "Linear Operator" implementation with a purely functional internal > representation. Block matrix internals would be easy. There will be lots of > implementations in the future; each will be clever in some way. It's > important that this cleverness be allowed to shine with minimal change to > the core matrix library.
Yes, the interface should be as independent as possible from the implementation. > Along these lines I think it's important that different implementations be > able to "take over" operations if they know how. For example we might create > a Diagonal Matrix representation which knows how to invert itself easily. > Perhaps matrices should have an _eval_inverse() method? Of course, maybe > this has been your plan all along. > > Also, with this separation of outward facing and inward facing matrices > maybe it will become easier to switch between mutable-fast and immutable but > Basic matrices. > > Completely unrelated - Should we consider a Solve operation rather than > always computing explicit inverses? If we wanted to get fancy we could > create an operator for this like Matlab does > Ax = b > x = A \ b %Matlab > x = A // b # SymPy? I think it is better to have a more verbose syntax here, like the current A.solve(b). Vinzent -- 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.
