The base idea is about modifying MatchPy in order to allow easy integration of MatchPy into SymPy and into the python bindings of protosym. Additional extensions to the project idea are welcome, provided there is enough time to complete them. Trying a translation of MatchPy into Rust has the potential of speeding up the library a lot, but it should be benchmarked.
On Tuesday, March 26, 2024 at 2:54:23 a.m. UTC+1 samithkar...@gmail.com wrote: > Is it worth for me to mention about the Protosym's architecture, in order > to strengthen my proposal ? or do I need more contributions in sympy > repositories. > > On Sunday, March 24, 2024 at 4:29:40 AM UTC+5:30 Samith Kavishke wrote: > >> Hi, >> Thank you, Francesco for your valuable insights. I have attached my >> current draft of GSOC 24 proposal. Can you help me with feedbacks for the >> proposal. >> >> >> On Tuesday, March 19, 2024 at 8:15:07 PM UTC+5:30 Francesco Bonazzi wrote: >> >>> No, no parsers are needed. Just a tree traversal for-loop. It's already >>> implemented: >>> >>> >>> - iterator >>> >>> <https://github.com/sympy/sympy/blob/94305f1976f84473f87d1b19d66ed9031b0c7e1f/sympy/utilities/matchpy_connector.py#L90> >>> - iterator size >>> >>> <https://github.com/sympy/sympy/blob/94305f1976f84473f87d1b19d66ed9031b0c7e1f/sympy/utilities/matchpy_connector.py#L99> >>> >>> As you see, in the current implementation we need to use >>> @op_iter.register... because "op_iter" is a MatchPy function that does not >>> exist in SymPy... With @op_iter.register we can extend it to a SymPy >>> object. The problem is: >>> >>> 1. @op_iter.register is an almost hackish way to do it, it messes up >>> with the class inheritance. We need something easier to use. >>> 2. The .register method defines the iterator on a class. We may have >>> cases in which we would like to have different iterators for the same >>> class... so it shouldn't be a class method. >>> >>> >>> On Monday, March 18, 2024 at 11:20:10 p.m. UTC+1 samithkar...@gmail.com >>> wrote: >>> >>>> 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 >>>>> samithkar...@gmail.com 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 sympy+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/8868dd31-df82-40b4-8552-6880d21afce0n%40googlegroups.com.
