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