These are chat archives for symengine/symengine
from csympy.lib.csympy_wrapper import densematrix
@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 : %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: 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.
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