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
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sympy@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---
