You need to give the full path name while importing. Do

You may try any of the examples in the test file.

`from csympy.lib.csympy_wrapper import densematrix`

You may try any of the examples in the test file.

@shivamvats, @Sumith1896 you can submit the same idea in the proposal, because if you both get accepted, we can amend the proposal/plan so that it becomes complementary. In fact, I would encourage you to submit what you feel the most passionate about. Here is an example of a series expansion that is ridiculously slow in sympy:

```
In [1]: %time (1/cos(x/log(x))).series(x, 0, 10)
CPU times: user 3 s, sys: 8 ms, total: 3.01 s
Wall time: 3.01 s
Out[1]:
2 4 6 8
x 5⋅x 61⋅x 277⋅x ⎛ 10⎞
1 + ───────── + ────────── + ─────────── + ──────────── + O⎝x ⎠
2 4 6 8
2⋅log (x) 24⋅log (x) 720⋅log (x) 8064⋅log (x)
```

It's a little non-trivial, as only the derivatives from the right exist at x=0, i.e. it's a Puiseux series, but I think things like this should be immediate. I bet the SymPy's own version can be sped up. Benchmarking should go against all the other software out there (GiNaC, Sage, Mathematica, ....).

As to implementing it, we should use single dispatch, see e.g. here: https://github.com/sympy/csympy/blob/master/src/eval_double.cpp#L195, and we can actually have few different versions of a series expansion module. One way is to specify "n" terms in the inner most expression, but some of them might cancel, so you end up with less terms (and so similar to how Arb works, you then keep doubling "n" until you get the number of terms that you need). Another version might work like in sympy, that it always gives you "n" terms.

I'll write more project ideas soon.

@certik I have been done some work in sympy ( although not in csympy ) and am also interested in series expansion project. Currently I am trying to fix the sympy/sympy#7529 which was part of last year's gsoc. Since other people are also considering series, I just wanted to ask whether multiple projects would be taken under the same issue ? Are students selected one/two per topic or is that flexible ? Please guide me.

@certik I've spent some time as to what api should be best for the Series class. Having a taylor-series is more of a design problem as optimization can be done at the function level. However the bottom-up approach you mentioned for the Puiseux seems very interesting. Could you elaborate on why it should be better than simply expanding for "n" terms?

@mihir-w as I wrote above, you are welcome to submit a proposal for series as well. Once students are accepted, we'll figure out a plan so that the work is complementary.

@shivamvats --- In SymPy, both approaches are bottom up, and in both approaches you correctly handle the order (

`O(x^n)`

) term. The only difference is how you handle the determination of how many terms should be computed. In one approach you choose "n" in the most inner expression and that's it. In the other you chose it carefully so that you end up with "n" terms in the end. As I said, this is similar to floating point evaluation ---- in sympy we currently carefully determine how much precision is needed (based on the operation) so that we get "n" digits in the end. That requires non-trivial logic. A better way seems to be to simply start with "n" digits, and calculate the final precision (which will be less than "n" digits). That's how `Arb`

does it.