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/1c5c0e08-ba4c-49bf-9bf0-51f0398ddad6n%40googlegroups.com.
