Hi, Eventhough have not been selected, do we still have a chance to continue the project? Without the stipend.
On Tuesday, April 2, 2024 at 7:14:15 AM UTC+5:30 Samith Kavishke wrote: > I have attached the changed version of this project. Thank you! > > On Monday, April 1, 2024 at 2:43:25 PM UTC+5:30 Samith Kavishke wrote: > >> 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 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/72653f6b-d10d-4281-8fcc-c662c47d942bn%40googlegroups.com.
