Le lundi 28 mars 2011 à 20:12 +0300, Andy Ray Terrel a écrit :
> On Mon, Mar 28, 2011 at 2:03 AM, Frank K. <[email protected]> wrote:
> > Thanks to everyone for suggestions and input. I was thinking of
> > implementing sparse matrix structures that would perform compression
> > by removing the excess zeros in a sparse matrix, rather than examining
> > any of the actual cell content. I can see that this might lose
> > efficiency if we save expressions that reduce to zero.
> >
> > Since I am new to the SymPy community, I am not exactly sure if this
> > was the aim of the summer project suggestion. To my understanding,
> > here are some goals/features of this functionality:
> >
> > - Abstraction of matrices so a user could call x.rref() and not worry
> > about whether the matrix x was dense or some flavor of sparse.
> > - Implementation of sparse matrix data structures
> > - Implementation of efficient algorithms for matrix functions for each
> > sparse matrix type
>
> No you shouldn't make "new" implementations of the algorithms rather
> make the interface such that the getting of elements is handled
> naturally.
>
I don't understand. Are you saying that the following is a good
algorithm to multiply sparse matrices?
def mul(A, B):
...
for i in range(A.rows):
for j in range(B.cols):
out[i, j] = sum(A[i, k]*B[k, j] for k in range(A.cols))
return out
> > - Conversion functions between sparse and dense matrices
> > - Users would be in control of the matrix representation, rather than
> > some sort of automated conversion (so, a default matrix would be
> > represented as dense, and x.toSparse() would convert it)
> >
> >
> > I would guess that a complete implementation of all of of those
> > features for multiple sparse data representations would take a lot
> > more time than a summer project would allow for. Does it seem feasible
> > to abstract the matrix module and fully implement one type of sparse
> > matrix for a 13 week project?
>
> So the design of the matrix should just conform to the current matrix
> interface, I don't think there is much to really to implement here. I
> would expect one storage scheme to take no more than a week to
> implement and fully test. Implementing more would be just a matter of
> changing the implementation. I have a hard time seeing the sparse
> matrix taking the entire 13 weeks but for a new coder perhaps.
There are a lot of ways in which the design of Matrix could be improved
(essentially, it tries to be both a pure Python reimplementation of
np.matrix and a representation of mathematical matrices but doesn't do a
good job of either) and it would be better to use this opportunity to
refactor it. Also, all the algorithms that re part of the interface will
have to be recoded - this should certainly take more than a week.
>
> I haven't worked on such large projects
> > before, so I am not great at estimating the time to complete a
> > project. Two things I am trying to avoid are ending up with a project
> > that requires 4 hours of work a week, and a project that requires 90.
>
> We would just expect a 40ish hour work week, if you don't finish what
> you want that is okay but if you don't get any work done that is bad.
> Your mentor should keep regular tabs on what you are doing to guide
> you so this situation doesn't happen.
>
> -- Andy
>
> >
> > Frank
> >
> > --
> > 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.
