CCing to sage-devel, could be interesting for Gary's symbolic code speed comparisons.
Ondrej On Jun 9, 9:18 am, "Ondrej Certik" <[EMAIL PROTECTED]> wrote: > On Mon, Jun 9, 2008 at 10:40 AM, Pearu Peterson > > <[EMAIL PROTECTED]> wrote: > > > Hi, > > > Just a quick note that could be relevant to the discussion: > > check also out > > >http://code.google.com/p/sympycore/wiki/MatrixSupportIdeas > > > that contains ideas how to deal with mutable matrices in > > operations where they should be immutable, all in a very efficient > > way. > > The idea is based on using views of matrices. > > Thanks for the tip. So what you do is that Matrix is writeable until > it is used in an expression? And you use this flag: > > " > Matrices are mutable until .is_writable==True. > " Yes. Basically, a matrix is mutable until its hash value is computed, that is, when matrix instance is used as a dictionary key. After that, the matrix will become automatically immutable. The is_writable flag can be used by inplace methods that then know whether matrices need to be copied or it will be safe to modify matrices inplace. > You seem you implemented some interesting ideas in sympycore -- would > you be interested in more collaboration and/or even merging the two > codebases? At least you write on sympycore webpage that "it is created > to fix SymPy performance and robustness issues", so let's point out > the robustness issues (I think we fixed all of them already, but if > there are some more left, let's fix that too) Robustness includes also a robust assumption model - my feeling is that robust assumption model requires an appropiate data model and I am not sure that sympy has it. > and as to speed, I'd be > interested in your opinions how to move forward. I'd be interested in > coming together for example before the EuroScipy sprint and work on it > together. But I think it'd be efficient to prepare some plan how to > merge it, or what to do. I think the plan that Fredrik proposed some time ago, would be a good start: try to use sympycore as an internal implementation of symbolic model in sympy and if it will be succesful, gradually remove unneeded layers. One can start with taking, say, the Add class and use sympycore data structures to represent its internal content and do manipulations with sympycore methods. To the rest of sympy, the Add would look like nothing had changed. Such a solution would not have the same speed as sympycore but if it will improve sympy speed in general, then it is already a positive sign and improving the speed further becomes just a matter of moving unneeded interface layers. > Anyone interested in this, please look how things are done in > sympycore and in sympy and let's start a discussion which way is good > to do things and implement it. And if there are two good ways (which > is very well possible), then let's find a solution to have both ways, > but with the same interface. Btw, I updated this morning the performance history page with sage results: http://code.google.com/p/sympycore/wiki/PerformanceHistory And interesting result is that sympycore is 3.5x slower than singular in this test. Not too bad for a Python solution compared to fastest symbolic library around. It would be interesting to try also the new sage.calculus code that Gary is working on but I was not able to find his code in sage sources.. Pearu --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
