These are chat archives for symengine/symengine

Feb 2015
Ondřej Čertík
Feb 15 2015 05:22
@irogerthat you can also write wrappers to other languages (I hope to eventually have official wrappers to many languages) and use it from those.
@shivamvats does the string hash function hash the whole string or just the beginning N characters?
Ondřej Čertík
Feb 15 2015 05:33
I read your proposal.mkd, and one things that is missing in there is the way the series is internally represented. I've been learning this myself lately, and by learning I mean trying all kinds of codes and representations. And it seems to me that the series should just call a dedicated polynomial library/code to handle the series. It seems to me that operations on a series are just polynomial routines, possibly with a cutoff (i.e. cut off all powers larger than N). So the question is, what the fastest polynomial representation is, and there it seems the sparse representation (hashtable) is doing the best. It seems the sympy.polys benchmarks show that it is doing really well even for short polynomials or "dense" polynomials compared to other representations (i.e. it is maybe just a little bit slower), and it is the fastest for sparse polynomials (that have many zeros in the dense representation). So we should finish implementing all subroutines that are needed in the and then use those in our Series class (no matter how we call it). This is definitely going to work for Taylor series, and I think it can be extended for Laurent. I am not sure about Puiseux yet. Once this is implemented and it works, only then we should translate to C++. As to CSymPy, we currently don't have a polynomial code. I am trying to use Piranha, or we need to write our own. SymPy already has the infrastructure. So a series proposal, in my opinion, should first implement that in SymPy, get it merged, and only then port to C++. Let me know your thoughts.
Also, it is not settled what the best way to represent polynomials is, and there will be optimizations in the future. So we do not want to duplicate any of this, we simply just need to use the polynomial code that SymPy has, and then if somebody speeds it up, then series itself will get faster. Analogous for CSymPy.
Ondřej Čertík
Feb 15 2015 05:43
So to conclude, it seems to me that the best way is to figure out how to just call a polynomial code and make the series code independent of the internal representation of the polynomials. If it is not fully possible, at least do our best, so that any future modifications in series are kept minimal, if somebody updates the polynomial code.
Shivam Vats
Feb 15 2015 09:41

@certik I'll answer in points:

  • I admit I haven't yet written anything about internal representation of the series, the reason being that I'm still not sure about the best way to do it. For small ordered univariate series, I was considering dense representation. However it seems(as you mentioned) having a sparse representation is better.
    I also talked to Avichal, who was trying to implement a dense FormalPowerSeries last year. He said he failed to integrate dense representation of Series with Sympy. So, perhaps, a sparse Series is the way to go.
  • As for a Series class for Sympy, we do have a starting point in this PR. We can cherry-pick the required commits and then modify them.
    Right now I'm not so sure what needs to be added to It should become clear once I start working on Series. Once that is done, I think it would be a good idea to also use the poly module for calculating limits (i.e in gruntz)

Now, regarding my proposal for the summer, the way I see it, it would be very difficult to get a Series class based on poly merged into Sympy before the application period ends. However, I don't yet see enough work in Series for Sympy for the whole of summer.

But what I could do is to get a working Series merged into Sympy in the first part of my project and then implement it in C++ in the second part. Is a cross Sympy-CSympy proposal possible?
Having said that, we still don't have our Polynomial module (in CSympy). If we do decide against using Piranha, I could implement it in C++, as Sympy's poly module is much more mature.
What do you think?

Sumith Kulal
Feb 15 2015 10:09
Adding to @shivamvats, I would say that the polynomial module be will very much necessary even in the implementation of solvers. Harsh who worked on improving SymPy solvers last year said that with the sets module extended,the solver was made exhaustive and consistent and easily extendible in future. So, action plan on implementation of other modules need be thought of, for solver, sets and polynomials being the necessary ones.
Sumith Kulal
Feb 15 2015 11:06
Some things like sympy.polys.polyroots are in direct relation with the solver, hence in my first half I can implement some of these. Since the polynomial module is vast, we have to think on what has to be implemented and what not.This is just a suggestion, we can discuss on this or any other alternatives. Your views @certik, @shivamvats ?