I will go through it and try to suggest a new method if time permits. Thank you Francesco you helped a lot to achieve this amount.
On Monday, April 1, 2024 at 2:27:15 PM UTC+5:30 Francesco Bonazzi wrote: > The issue I see in the proposal is that the methods should probably be > functions, not class methods. If we keep class methods we are probably > still forced to use subclassing (I would like to avoid that). Anyways, it > looks good, this is just a minor issue > > On Tuesday, March 26, 2024 at 12:07:15 p.m. UTC+1 Francesco Bonazzi wrote: > >> 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 [email protected] >> 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 >>>>> [email protected] 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 >>>>>>> [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/a5958838-e018-455c-be5f-751ba1598964n%40googlegroups.com.
