On Tue, Apr 22, 2014 at 5:11 PM, Ondřej Čertík <[email protected]> wrote: > 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.
No, I think it is still linear even for O(n^3) problems. If it has n^3 operations and each operations takes 100x less with CSymPy, the whole calculation still takes 100x less with CSymPy. Ondrej > >> >> >>> 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/CADDwiVDC8ZKBDDv3e_M0idEkAsrk5AN-oqR7npPhipqGfcdrpA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
