On Tue, Apr 22, 2014 at 3:58 PM, Joachim Durchholz <[email protected]> wrote: > Hm. > > One: >> * Extension/complement to SymPy > > Two: > > >> That lowers the barrier >> of entry significantly, compared to a big mix of C++, Cython and >> Python, makes it easier to make things fast >> (you don't need to worry about Python at all). > > > That's not an extension nor a complement, it's a replacement. > > >> The Python (and other >> >> languages) wrappers should be just a thin >> wrappers around the C++ core (=just better syntax). > > > I.e. replace the engine if not the API. > > Not that I'm judging. I'm just pointing out perceived inconsistencies. > > The more SymPy itself turns into a set of simplification rulese, the less > significance this will have in the end. > > >>> - How will CSymPy be architectured to allow things to happen in CSymPy >>> when they can but fallback to SymPy when they cannot. >> >> >> Currently you can simply mix and match SymPy and CSymPy expressions. >> So you simply >> convert an expression to SymPy to do some advanced manipulation, and >> convert to CSymPy >> to do some fast manipulation. I am open to suggestions how to improve >> this. > > > The alternative would be to have a data structure that can be manipulated > from both the C++ and the Python side, but that's going to be unnatural for > at least one of the sides. > > Note that the data structures can become large-ish, and if the > simplification becomes complicated there may be a lot of back-and-forth. > It's possible that mixed execution will be slow for some algorithms or use > cases for that reason. > > I do not think that this can be determined in advance, it's something to > keep an eye out for during benchmarks. > > >>> My main concern here is that CSymPy has not clear separation from >>> SymPy, and as a result it will end up growing larger and larger, until >>> it becomes an independent CAS (which is fine if that's the goal, but >>> my understanding was that it was supposed to be just a small fast >>> core). >> >> >> The goals are written above. I am myself concentrating on speed, >> that's what I really >> want to nail down. > > > I'm somewhat sceptical about this. > A conversion to C++ will give a linear improvement. > Better algorithms can improve the big-Oh class. > Unless algorithmic improvements have been exhausted, this would be premature > optimization. (Are algorithmic improvements exhausted yet?)
For the basic manipulation pretty much. One can get faster than the current sympy, see e.g. sympycore. But you don't get as fast as current CSymPy with that approach. The speedup is linear for O(n) problems. For O(n^3) problems (Gaussian elimination [1]...) the speedup is cubic. So it really matters for these kind of problems. > > >> However, let's say somebody comes and reimplements the Gruntz >> algorithm in CSymPy. Should we reject such a PR? My answer is that if >> the code is nice, >> maintainable, much faster than SymPy and has the same or similar >> features, I am ok >> with merging it. > > > Hm. It does excludes those with lack of C++ background will be excluded from > maintaining it. > Which means that the code instantly loses a lot of maintainability. > > It's the main reservation I'm having about what the CSymPy project is doing. > This is the usual problem with dual-language projects. "Pure Python" is one > selling point of SymPy, and I think it's an important one - the point of > having Open Source is that in times of need, you can take a look at what's > going wrong, having a dual-language project eliminates that advantage for a > large fraction of users. Right, that's why we are sticking to just one language, as opposed to have mixed Python / C++ code, which would bring a lot more intricacies. Yes, you have to learn the language in order to contribute, but that's it. You don't need to learn two languages and how to mix them. (The Python wrappers that we have are simple and thin, i.e. there is no logic there, so if worse comes to worse, I can maintain them myself.) SymPy will stay pure Python. You raise some good points, but I don't know a better alternative. As I said, I can deliver using C++. I tried other approaches, and I failed to deliver using those. That does not mean that there is some better way of course, only that I don't know any other better way. Ondrej [1] http://en.wikipedia.org/wiki/Gaussian_elimination#Computational_efficiency -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CADDwiVDjgDP_eJEb9sHfx3sHt5WM9ouJw-A6t-0TL3XuP1t39Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
