sparsematrix upgrade

[smichr]

I've spent the last several days trying to incorporate Sherjilozair's smallchanges PR into matrices.

matrices is still rough in design, namely there are lots of methods in MatrixBase that should probably be in MutableMatrix since SparseMatrix derives from MatrixBase and Sparse's .mat is a dictionary while Matrix's .mat is a flat list of row-wise elements. To keep make it clear when a method shouldn't work with Sparse I've changed Sparse's .mat attribute to .smat so if a method is called on Sparse that is defined in MatrixBase (but really should be in MutableMatrix) it will now fail. smat and mat should probably be private methods.

I hope lack of the ideal will not keep someone from looking at this and considering the significant upgrade. I also un-XFAILed the test suite for SparseMatrix which has been un-run since almost the begninning of SymPy (about 10,500 commits ago where an immediate return was added).

If there are any changes that one wants to make, feel free to take over the branch and make the changes. Just as there is no end to the writing of books, there is no end to changes that can be made...only the possibility of trading one work for another :-)

The coverage is above 92%.

Best regards,

 Christopher Smith

[Matthew Rocklin]

What methods were you thinking of moving from MatrixBase to MutableMatrix? Are these methods also relevant for ImmutableMatrix?

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.

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.

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?

--
You received this message because you are subscribed to the Google Groups "sympy" group.
To view this discussion on the web visit https://groups.google.com/d/msg/sympy/-/Uiq4i-Oo20cJ.
To post to this group, send email to sy...@googlegroups.com.
To unsubscribe from this group, send email to sympy+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sympy?hl=en.

[Chris Smith]

On Wed, Sep 26, 2012 at 6:11 PM, Matthew Rocklin <mroc...@gmail.com> 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.