On Wed, 6 Oct 2021 at 23:36, Francesco Bonazzi <[email protected]> wrote:
> > It would be curious if we could rewrite SymPy's core using MatchPy. I > mean, there have been some development with a lot of code developed to > properly handle the subclassing (or .kind property, that has been > introduced now) the *Add* and *Mul* classes, especially their flattening > algorithm. Multiple dispatch was an initial idea, but it's not quite > optimal to use. > > I would like to point out that all of these issues are practically solved > if we use MatchPy. The pattern matcher does not just dispatch on the types > of the expressions, but also on the expression substructure. > I do agree and this is more or less the direction I would like to go with SymPy. To me it seems that the fundamental problem is Basic and automatic evaluation: SymPy does not provide the right data structures for these algorithms to work properly. I don't think it's possible to make the changes needed for this kind of rewrite within SymPy itself without a massive compatibility break though. In fact even if it was considered acceptable to break compatibility to the extent needed I don't think that it would be tractable to try and make the changes directly in SymPy. My approach would be to make a new library that redefines the core of SymPy itself and that uses matchpy or equivalent. Then if that library could be made compatible with SymPy through a mechanism like sympify then it would be possible to work incrementally on it until it was relatively complete. The new library could be unencumbered by backwards compatibility constraints and could fix the known design flaws by having first-class functions, exp as pow, no automatic evaluation, kinds and kind checking built in, match-based assumptions, better handling of singular cases in basic manipulation, ... Then SymPy itself could be made to depend on that library (and therefore indirectly on matchpy) and use it internally while still allowing users and downstream libraries to work with their old Basic subclasses. At the point when a new core works and is usable we could consider what to do with old Basic. If SymPy already gets most of the benefit of the new core by using it internally in key routines like solve, integrate (RUBI), etc we can consider to what extent it is worth maintaining the old core. We could also consider at that point whether it's worth moving the new library into the main sympy codebase or if it's better just to keep it standalone. If the new library and its approach with matchpy turns out not to be useful then no real harm would be done (apart from potentially wasting our time). The old core and all of the rest of it would still work, we wouldn't have added a dependency for something that wasn't actually needed and we wouldn't have broken any compatibility. Basically I think that there needs to be a plan. I don't think we should make user-visible changes like breaking compatibility or adding dependencies until we're clear what the plan is and we're ready to provide some tangible benefit to users. My vision of the SymPEP process was not so much that it should be about making decisions but about discussing and documenting what we want to do and why, especially for situations where it will take a long time to implement the proposal and would need many people to work together. I think that what we should do right now is set up a video call to discuss this rather than going back and forth here. Do you want to meet and discuss this? -- Oscar More MatchPy rules could be loaded in other SymPy modules (for example, if > you load *sympy.matrices* the rules for flattening on *Add* and *Mul* for > matrices will be added). Postprocessors could then be done away with. > > For efficiency, MatchPy can generate a Python decision tree performing the > rule matching (note: you lose the possibility to dynamically load more > rules once the code has been generated). > > Furthermore, there is a code generator in SymEngine targeting C++, which > could potentially be used to compile algorithms written for SymPy in Python > with MatchPy's rules into C++ code compatible with SymEngine (one quick > note, this module is still in its early stage). > On Wednesday, October 6, 2021 at 10:50:32 p.m. UTC+2 [email protected] > wrote: > >> On Wed, Oct 6, 2021 at 2:10 AM Francesco Bonazzi >> <[email protected]> wrote: >> > >> > >> > >> > On Wednesday, October 6, 2021 at 12:46:25 a.m. UTC+2 [email protected] >> wrote: >> >> >> >> Since we are bringing up SymPEPs again, it would be helpful to agree >> >> on the actual SymPEP process itself. There hasn't been much discussion >> >> on https://github.com/sympy/SymPEPs/pull/2 for a while. >> >> >> >> I was also hoping we could have a general PEP about dependencies and >> >> conditions for when something should be added as a hard or optional >> >> dependency. >> > >> > >> > The problem with SymPEP is that we will rarely use them. I mean, it's >> quite rare to have a proposal for a major change in SymPy. >> >> I agree SymPEPs will be rare and indeed should be rare. Such a formal >> process is only needed for major changes where we should try to avoid >> making bad decisions. I don't see how this is a problem though. I >> would say having such a formal process only be used rarely is a good >> thing. >> >> Aaron Meurer >> >> >> > >> > -- >> > 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/e0680e96-8268-4bf8-ba9e-9afc75d42697n%40googlegroups.com. >> >> > -- > 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/61ab2404-c9f7-4eaf-9255-b790d89a298fn%40googlegroups.com > <https://groups.google.com/d/msgid/sympy/61ab2404-c9f7-4eaf-9255-b790d89a298fn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAHVvXxSF-437t151vmPq0kdbWeExegWAy7MX_u2_8gjY%3Dmk%2BMA%40mail.gmail.com.
