On Tuesday, October 5, 2021 at 2:07:06 p.m. UTC+2 Oscar wrote:
> > 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. > SymPy can still be modified in order to use a pattern matcher. Also, MatchPy has been partly translated into C++ inside the SymEngine project: https://github.com/symengine/symengine/tree/329a04be017daff0362b9177da2ef5b7e5d605f7/symengine/utilities/matchpycpp > > 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. > The benefits are mostly for SymPy development. You can start defining replacement rules to implement new algorithms. > 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. > This can be done. > 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. > Consider that it's pretty common now for libraries to depend on other libraries. An alternative would be to copy the MatchPy project as a subfolder inside SymPy (as it has been done for the *multipledispatch* module). > 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. > The major downside is probably that MatchPy has not been extensively tested with SymPy. There is a risk factor in relying on a new library. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sympy/003f5fd9-8137-40eb-a8a6-ca2378a08ccan%40googlegroups.com.
