On Tue, Mar 29, 2011 at 11:35 PM, Matthew Brett <[email protected]> wrote: > Hi, > > On Tue, Mar 29, 2011 at 11:43 AM, Andy Ray Terrel <[email protected]> > wrote: >> On Tue, Mar 29, 2011 at 7:22 PM, Aaron S. Meurer <[email protected]> wrote: >>> >>> On Mar 29, 2011, at 12:51 AM, Andy Ray Terrel wrote: >>> >>>> On Tue, Mar 29, 2011 at 9:13 AM, Tim Lahey <[email protected]> wrote: >>>>> On 03-29-2011, at 1:44 AM, Andy Ray Terrel wrote: >>>>> >>>>>> There are some major confusions on this list about the difference >>>>>> between algorithms and storage. >>>>> >>>>> I'm not confused and I'm not sure if other people are. I just think >>>>> storage alone isn't suitable for a GSoC project. Certainly one could just >>>>> implement storage techniques behind the scenes and no algorithms, but >>>>> that would only save space, not computation time. >>>> >>>> On modern hardware, computation is free memory is expensive. >>>> >>>>> >>>>>> Yes, it is typical to use iterative >>>>>> algorithms with sparse matrices and factorizations with dense, but >>>>>> this is because sparse matrices are typically very large (1M -- 10^12 >>>>>> entries with 1000 -- 2B non-zeros). One will switch to things that >>>>>> don't fill in the matrix but SymPy will probably never be at this >>>>>> level. >>>>> >>>>> With symbolic matrices, the computation time for each calculation is much >>>>> higher than with numerical matrices so the benefit of sparse matrix >>>>> techniques occur at much smaller matrix sizes. >>>>> >>>>>> One can implement some Krylov subspace iteration algorithms, >>>>>> but its somewhat pointless (how do you evaluate a residual in >>>>>> symbols). Another algorithm ILU versus LU is also silly (basically it >>>>>> throws away small fill in entries but we have no way of saying what is >>>>>> small in symbolics). For this reason I suggest just implementing >>>>>> standard factorizations and dealing with the fill in as it happens if >>>>>> we get to the point that we need to do UMFPACK style direct >>>>>> factorizations we can do that the next summer. We practitioners only >>>>>> use "algorithms suited for sparse matrices" because of the size of the >>>>>> matrices which will not be an issue in SymPy. >>>>> >>>>> I've already stated that storage isn't suitable for a GSoC project. >>>> >>>> I respectfully disagree. Furthermore I find it distasteful for one >>>> applicant to tell another that their idea is not suitable. >>> >>> Let's remain civil. I think it is important to decide what is needed and >>> what is less needed, or what will be better than the current (dense) >>> implementation and what will actually end up being worse. >> >> Please give me your guide of civility so I can rip out every page and >> use it as toilet paper. > > I don't think that will serve you well, civility is very important: > > http://www.codesimplicity.com/post/open-source-community-simplified/ - > see 'Encourage a total absence of personal negativity'. > http://producingoss.com/en/setting-tone.html see 'Nipping rudeness in the bud' > > Best, > > Matthew >
Matthew, I would agree that civility is important, but any civility guide that tells a person not to speak up with another is attacking a student's proposal is as useful as toilet paper. This thread has become a diatribe of opinions. Nevertheless, Frank, you should submit this proposal and continue to submit a patch for the GSOC application. -- Andy -- 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.
