On Wed, Sep 26, 2012 at 6:11 PM, Matthew Rocklin <[email protected]> wrote: > What methods were you thinking of moving from MatrixBase to MutableMatrix? > Are these methods also relevant for ImmutableMatrix? >
Anything that is dense-related should be outside of MatrixBase, e.g. transpose should be generic, calling `_eval_transpose` and that's all. Then each matrix overrides the not-implemented _eval_transpose. It's not like that right now. decomposition methods that work on every element (accessing `._mat`) should be in Mutable (or Dense) not in MatrixBase. MatrixBase should just contain the implementation-agnostic methods like shape, rows, cols, etc... or anything that can be written generally, like adjunct = M.conjugate().transpose() (or something like that). > Background: MatrixBase was created when ImmutabileMatrices were created. It > is effectively all of the shared code between MutableMatrix and > ImmutableMatrix. It could more accurately be called DenseMatrix. It would be > reasonable to factor out a large chunk of MatrixBase into something more > general that could be more easily shared with SparseMatrix. > Sherjilozair introduced a whole bunch of different matrix implementations that may be patterned after sciipy. I'm not sure why one needs all the different flavors beyond chocolate (dense) and vanilla (sparse). > Perhaps we should do the following: > Rename MatrixBase -> DenseMatrix > Create new MatrixBase and factor out some agnostic code into it. > > Do you have a branch or pull request that we should look into? At this point > I'm not willing to take on SparseMatrix (work is busy) but I am willing to > review. Yes (and thanks) please look at #1535. It's not perfect, but it's a whole lot more functional, covered, and tested with disambiguation of the storage schemes of Mutable and Sparse. I just want to move the ball forward, I am not going for a touchdown here. > > Also, can someone repost why SparseMatrix is important? It is important > internally, right? How quickly after creating a good SparseMatrix > implementation would SymPy reap these benefits? > I can't help here, but the solve methods (including least_squares) are now part of Sparse so that's a new aspect that is functional. -- 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.
