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 ? -- 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.
