> > > I think once we stop supporting Python 2.7, we can start using static > typing > quite easily and I think it helps. > > That will be a long time, maybe 2017-2018 ? I'm just giving a naive estimate.
Though I think one of the most useful algorithms in SymPy that are > candidates for C++ rewrite > are polynomials, and those as far as I know don't use much duck typing, so > it should be fairly easy to rewrite using fast native C++ datastructures. > For example, here is my implementation of sparse polynomial multiplication > in C++: > > https://github.com/certik/csympy/blob/master/src/rings.cpp#L63 > https://github.com/certik/csympy/blob/master/src/monomials.cpp#L7 > > and I think it might be possible to speed it up further by playing > with the hashtable > and hashes and similar things. I tried to optimize a hash function for > this case already, > see here: > > https://github.com/certik/csympy/blob/master/src/dict.h#L48 > > the idea is that the hash function needs to be fast to compute for the > tuple of ints and > also as unique as possible. > Experiments on data types can be made in Python too. Python has basically three complex data-structures (I mean, the most common used): tuples, lists, dicts. But in C++ a list can be different things. For example, in STL there are * vector* and *list*, vector fits better for fixed-length arrays, while lists is good if you have to append/pop elements. Python offers only a *list* object, but in many cases it would be useful to choose the array-like data structure that fits best. And by the way, if one already knows the size of the array, he should be able to pre-allocate the dimension of the list object. I would try first to put this in Python, that would be a good point in easing translation and efficiency. Btw, I don't want to discourage you from trying things. I only wanted > to share my own > (hard-earned) experience, as I tried various approaches. For example, > one great project > would be to implement similar symbolic core in Julia. It might get > competitive or even > faster than my Cython version above. Whether it could match my C++ > version, > that I don't know. > > It is possible that over the time new programming languages with powerful feature will start to emerge, in any case I would not commit too much time to optimization. You know, it's a continuously evolving subject, unrelated to just SymPy, maybe in the future a new technology will appear making things easier and faster. I would rather keep an eye an websites and papers related to optimization. Trying hard on one way today, may turn up having being futile in the future. On the other hand, adding new features to SymPy is always good. -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sympy. For more options, visit https://groups.google.com/groups/opt_out.
