These are chat archives for symengine/symengine

15th
Dec 2015
Ralf Stephan
@rwst
Dec 15 2015 09:18
Oh my, did I poke into a canof worms. Noticing that SymPy buildup of expressions is inherently slower and slowing our good benchmarks. Reason: sympy/sympy#5954
Isuru Fernando
@isuruf
Dec 15 2015 09:30
@rwst, did you check timings without creating Add objects every time. i.e. making a list of Mul objects (Pow*coef) and then passing it to Add?
Ralf Stephan
@rwst
Dec 15 2015 09:32
well how should I (or any user) know? That's a big design fault because Pynac has no such problems.
Isuru Fernando
@isuruf
Dec 15 2015 09:34
Ah. That should be documented well. SymEngine also has that problem, because all objects are immutable and therefore more objects are made.
Ralf Stephan
@rwst
Dec 15 2015 09:42
@isuruf Sorry do you have simple example? I cannot find it...
@isuruf ah ok not necessary
Ralf Stephan
@rwst
Dec 15 2015 09:52
This is ridiculous:
In [1]: l = list(x**i for i in range(1000))

In [2]: time _ = Add(*l)
CPU times: user 144 ms, sys: 44 ms, total: 188 ms
Wall time: 147 ms

In [3]: l.append(O(x**1001))

In [4]: time _ = Add(*l)
CPU times: user 28.9 s, sys: 28 ms, total: 28.9 s
Wall time: 28.9 s
Isuru Fernando
@isuruf
Dec 15 2015 13:37
@rwst, @certik, For series and polynomials, should they extend the Basic class or be outside Basic. I'm asking this because they are inherently different than others. For example, addition results in an Add normally, but Polynomial + other Basic = Polynomial.
We could have an implicit conversion to Basic for things like eval_double to work automatically.
I haven't really thought this through, but what are your comments?
Ralf Stephan
@rwst
Dec 15 2015 13:53
In Sage they have the coercion system which is based on category theory, so my opinion is biased when I say neither will be sufficient in the long run. Please see http://doc.sagemath.org/html/en/tutorial/tour_coercion.html as a start.
Ralf Stephan
@rwst
Dec 15 2015 14:06
To put your example in the Sage perspective, series can be in different rings depending on the coefficients (symbolic, real, rational), the exponents (power/Laurent/Puiseux series), and be uni/multivar. As series can be seen as polynomial+order term (where polynomials have order infinity) the choice of class hierarchy, were it only about series and polys, would be easy: Subclass one from the other.
Isuru Fernando
@isuruf
Dec 15 2015 14:06
Correct me if I'm wrong. Since SymEngine's types are different and one cannot be another (for ex. an integer can never be a Rational type), for the existing functionality we need just one ring (Call it Symbolic Ring). This is different to Sage where an integer can be a Rational and therefore sage needs different rings like ZZ and QQ.
Ralf Stephan
@rwst
Dec 15 2015 14:10
They have a symbolic ring in Sage as well, additionally to all that. And Sage can create a polynomial ring with symbolic coefficients, which would be just right, because you don't need symbolic exponents.
Or maybe not, for general expressions there is only one choice, a symbolic ring. I say "a" because recently the capability was created to subclass from SR, in order to have specific symbolic rings, e.g. without constants.
Isuru Fernando
@isuruf
Dec 15 2015 14:15
@rwst, yes, I've used it in Sage. One thing I noticed is that, expressions like sin(t) is allowed where t is a polynomial. How does that work?
Ralf Stephan
@rwst
Dec 15 2015 14:18
Other Python types can be wrapped in Expression. But that does not really solve the math, just to be able to create and print them. Countless bugs are associated with that because the user expects someting which is not there.
*something
Also sin(poly) is expected to return a poly (same type in/out) which creates a heavy duty on who writes function code. IMHO this should return a series, like in Pari.
Isuru Fernando
@isuruf
Dec 15 2015 14:23
I think sin(series) giving a series is something that would be useful, but sin(poly) should return sin(symbolic) where poly is converted to symbolic
Ralf Stephan
@rwst
Dec 15 2015 14:25
Yes why not, it would make sense, but what do you do with a matrix, or a p-adic?
Isuru Fernando
@isuruf
Dec 15 2015 14:27
I'm sorry, I didn't get what you said
Ralf Stephan
@rwst
Dec 15 2015 14:33
I mean there is a combinatorial explosion when it comes to symbolic expressions. sin(matrix) and sin(p-adic) can be well defined too.
Isuru Fernando
@isuruf
Dec 15 2015 14:46
Then sin should be able to accept all types of objects even if it is not in symbolic ring.
Which means the answer to the original question would be to extend Basic to Polynomial and Series
Ralf Stephan
@rwst
Dec 15 2015 14:52
Agree.
Isuru Fernando
@isuruf
Dec 15 2015 16:00
Just to be clear, insin(matrix) you meant Sin object, right?
Ralf Stephan
@rwst
Dec 15 2015 16:01
Ah no, sin the function.
Isuru Fernando
@isuruf
Dec 15 2015 16:03
Then the arg of Sin class only has to be Symbolic right? At the moment, in sage, arg of a sin can be a polynomial
Ralf Stephan
@rwst
Dec 15 2015 16:09

It should be able to take everything but doesn't:

sage: sin(matrix())
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
...
TypeError: cannot coerce arguments: no canonical coercion from Full MatrixSpace of 0 by 0 dense matrices over Integer Ring to Symbolic Ring
sage: SR(matrix())
[]
sage: type(_)
<type 'sage.symbolic.expression.Expression'>

which is a bug IMHO because usually everything coerces into SR.