I think, I understood the point you are making. If we are going to redefine the tree structure in matchpy using overridable methods, does that mean we have to use a parser to translate the sympy object type to matchpy or are there any better way to handle the situation. On Saturday, March 16, 2024 at 8:32:03 PM UTC+5:30 Francesco Bonazzi wrote:
> I suggest to start the unit tests of MatchPy in debug mode and follow the > tree traversal to get some more insight. Indeed, the code is quite > complicated, but the debugger may help. MatchPy also provides a tool to > dump the state into a GraphViz dot file. > > The idea is that matchpy_connector should not use all those ".register( )" > methods, it should not have objects subclassing MatchPy objects (currently > there is Wildcard). > > On Saturday, March 16, 2024 at 1:52:55 p.m. UTC+1 [email protected] > wrote: > >> Hi, >> Still I am in the process of understanding the matchpy code base. >> at the moment I understand that, >> >> - Isinstance logic should replace to overridable method or any >> preferred way ( wrappers around classes new classes also possible without >> changing the existing code). >> - __iter__ logic should change due to the tree traversal must change >> accordingly, because it is rely on the inheritance. >> - replace method in the matchpy connector should change because it is >> replication of same code twice. >> - Enhance the capability of matchpy_connector, because still does not >> have the capability of solving calculus, matrices and more advanced >> problems. >> >> what are the other things that might affect if we add overridable method >> to Expressions? any suggestions for me to refer. >> On Wednesday, March 13, 2024 at 2:04:20 PM UTC+5:30 Francesco Bonazzi >> wrote: >> >>> On Wednesday, March 13, 2024 at 8:13:27 a.m. UTC+1 Aaron Meurer wrote: >>> >>> As far as we can tell, SymPy is the only thing that uses MatchPy, >>> outside of the specific research software from that research group >>> that it was developed for. >>> >>> >>> Indeed, MatchPy is probably very underappreciated. Its developers >>> haven't really advertised it enough. >>> >>> >>> If making MatchPy more SymPy specific eases >>> the development burden, we should do that, especially if we are going >>> to fork it anyway. I think the core of it does need to remain >>> independent of SymPy's types, especially if we want to try to write a >>> Rust backend. >>> >>> >>> I would still make an attempt at keeping it generic. The main issue is >>> removing all "isinstance( ... )" and "__iter__" statements in the >>> expression tree traversal algorithms of MatchPy and replace them with more >>> generalizable statements. I'm confident this can be done and that we can >>> still keep MatchPy generalizable to other libraries. >>> >> -- 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/b08ff4c8-e9b2-4455-85b8-d65af42462a2n%40googlegroups.com.
