These are chat archives for symengine/symengine

2nd
Feb 2016
Ralf Stephan
@rwst
Feb 02 2016 07:09
That SymPy issue sympy/sympy#10262 is making our fine series speed irrelevant.
Isuru Fernando
@isuruf
Feb 02 2016 07:52
I was thinking of not converting to SymPy at all.
Ralf Stephan
@rwst
Feb 02 2016 07:54
What happens is that symengine.py gives to SymPy something like Add(x**2, Add(x**4, Add(...,O(x**1000)))) and SymPy, when flattening this, tests for each term if it is contained in O(x**1000). Since order terms can be pretty complex, the algorithm for this ("Gruntz algorithm") is pretty slow. Because of the way this is organized this can only be resolved if the algorithm is improved, and I think it's straightforward, i.e. special case for order terms of form x**N.
Isuru Fernando
@isuruf
Feb 02 2016 07:55
Why not have a Series class in symengine.py that extends Basic and stores a RCP<const SeriesCoeffInterface> in it?
Ralf Stephan
@rwst
Feb 02 2016 07:56
and if someone adds 1 or say oo we must handle all of it, instead of delegating to SymPy
Isuru Fernando
@isuruf
Feb 02 2016 07:57
Adding 1 or taking sin of a series is okay
Ah no, taking sin is not implemented yet
Ralf Stephan
@rwst
Feb 02 2016 07:58
if you have a new type, everything is new
Isuru Fernando
@isuruf
Feb 02 2016 07:59
Only problem is something like series + x**2 although series + series is okay
Ralf Stephan
@rwst
Feb 02 2016 08:01
I don't want to discourage you, both solutions can be implemented. Some time later we could even have our own Gruntz.
Isuru Fernando
@isuruf
Feb 02 2016 08:02
Okay. I'll ping you once I have something working
Ralf Stephan
@rwst
Feb 02 2016 08:03
me too, but you're usually faster 8)
Isuru Fernando
@isuruf
Feb 02 2016 08:07
:D
Ralf Stephan
@rwst
Feb 02 2016 16:03
@isuruf OK I have a first patch and numbers in sympy/sympy#10513
The bad performance in C must have something to do with size of coeffs
Isuru Fernando
@isuruf
Feb 02 2016 17:01
Yes, that could be possible. Is it conversion that takes the most time or the Order in C?