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?)
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.
--
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/5356E621.1030701%40durchholz.org.
For more options, visit https://groups.google.com/d/optout.
