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

@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?

well how should I (or any user) know? That's a big design fault because Pynac has no such problems.

Ah. That should be documented well. SymEngine also has that problem, because all objects are immutable and therefore more objects are made.

@isuruf ah ok not necessary

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

@rwst, @certik, For series and polynomials, should they extend the

We could have an implicit conversion to

I haven't really thought this through, but what are your comments?

`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?

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.

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.

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.
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.
@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?
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.
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`

Yes why not, it would make sense, but what do you do with a matrix, or a p-adic?

I mean there is a combinatorial explosion when it comes to symbolic expressions.

`sin(matrix)`

and `sin(p-adic)`

can be well defined too.
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

Just to be clear, in

`sin(matrix)`

you meant `Sin`

object, right?
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
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.