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.
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? On Tue, Jul 12, 2011 at 3:02 PM, Vinzent Steinberg < [email protected]> wrote: > On Jul 11, 2:46 pm, SherjilOzair <[email protected]> wrote: > > For those who've not read my latest blog, I'm working on implementing > > a new structure for the matrices module of sympy. > > I faced many decision problems while doing so, like what should be > > named what and what should be where. > > > > Should matrix and linear algebra be separated ? > > > > I'm +1 for minimal code in the matrix class and most of the > > code(factorizations, solves) outside the class. > > > > What all functionality have we or should we *promise* to the users of > > sympy ? That is, what is the public API ? > > > > Since you guys have been using sympy matrices for a long time, it > > would be best if you could reply back with what do you expect the > > matrix module to behave like ? > > > > One thing that I'm promising is user indifference to internal > > representation, i.e. the user can ignore the representation of the > > matrix to be chosen and matrix class will figure out the > > representation, and there will be seamless conversion between the > > matrix internals. An algorithm that works on dense matrix would even > > work on sparse matrices without the user explicitly doing any > > conversions. > > The user will still be able to override and choose the repr himself my > > a 'repr' kwarg like Matrix(..., repr='dense'). > > > > I plan to put only essential functionalities in the main class. Other > > functionalities will be put in a separate file matrixtools.py or > > matrixutils.py. > > For example, jacobian does not belong to the class, it belongs to > > specialmatrices.py, and should be in the linalg. namespace as > > linalg.jacobian > > I've encountered many stuff like this like this in the matrices.py > > file. > > > > so, once again the questions are, > > What do you expect from the matrix module ? > > What should be the public API ? > > What functionality should be given special status to reside inside the > > class ? > > I think we should do it like numpy and prefer for example lu_solve(A, > b) over A.lu_solve(b). On the other hand, we have usually both in > sympy. > > Vinzent > > -- > 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. > > -- 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.
