On Tue, 5 Oct 2021 at 07:48, Francesco Bonazzi <franz.bona...@gmail.com> wrote:
> Hi everyone, > > I have written a draft for a SymPEP (SymPy enhancement proposal) to > include MatchPy as a dependency of SymPy. > > https://github.com/sympy/SymPEPs/pull/3 > For those less familiar to github you need to click the "files changed" tab to actually see the text of the SymPEP. A direct link is: https://github.com/sympy/SymPEPs/pull/3/files > Once SymPy depends on the MatchPy library, the bindings to MatchPy can be > moved into SymPy's core. > > MatchPy provides a much more powerful pattern matcher than the current one > implemented in SymPy's core. In particular: > > - it can match multiple patterns at the same time and very efficiently > (SymPy's matcher can only process one pattern at a time), > - it can generate a decision tree in Python out of multiple patterns > (SymEngine has an implementation to generate a C++ decision tree out of the > same patterns). > > Feel free to join the discussion either here or on the [SymPEP Pull > Request](https://github.com/sympy/SymPEPs/pull/3) > > I think it's best to discuss this here rather than on the PR apart from discussion of minor edits. I agree that pattern matching is a crucial part of a CAS and should really be the core of SymPy. If I was redesigning SymPy from scratch then everything would be built on top of a pattern-matching engine and almost all of the logic from the myriad Basic subclasses would just be written as pattern rules. My equivalent of SymEngine would just be a C implementation of the pattern-matching engine rather than a repeat of the object-oriented design of SymPy. I also agree that matchpy looks like a good implementation of pattern-matching and it makes sense for it to be usable with SymPy. What the SymPEP does not address though is what benefit is gained for users by making matchpy a non-optional dependency. The examples shown look like somewhat specialised usage for which an interested user could just choose to install matchpy. RUBI would be a good motivation but as far as I can tell RUBI does not yet work. Actually I would prefer it if RUBI was already in a separate package from SymPy - it should not have been merged until it was at least partially working. The rubi_tests folder is included for all users and includes e.g. the sympy/integrals/rubi/rubi_tests/tests/test_trinomials.py file which wastes at least 1.5MB disk space for every single SymPy user for precisely zero benefit (these tests should clearly be in a separate repo). I don't see how making matchpy a non-optional dependency would make it any easier to improve RUBI since anyone who wants to work on it can just install matchpy. In fact if RUBI was not in the main SymPy repo then it could have a hard dependency on matchpy. The cost of making matchpy a non-optional dependency would be felt by downstream distributors of SymPy who would then have an additional dependency to include. It would also be felt by all users of SymPy with longer install time, more disk space etc. If a user does not use any of it's features then this cost comes with no benefit. I am not saying this to disagree with the proposal but that there needs to be a clear rationale for making matchpy a hard dependency and the SymPEP does not address this at all. The SymPEP should also clearly spell out what the downsides of the proposal are. -- Oscar -- 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 sympy+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAHVvXxSKXmwcd1m7G%2Bo10%3DfCU7%3DESbUjgwHMjQDZ8R0N%2Bp-gNg%40mail.gmail.com.
