Hi Samith. You are always free to contribute to SymPy independently of GSoC, as it is an open source project and you can always contribute to an open source project. We can't guarantee you the mentorship that a GSoC contributor would receive. It would be up to Francesco and other community members if he is interested in helping out with this project.
Aaron Meurer On Wed, May 1, 2024 at 7:58 PM Samith Kavishke <samithkarunathil...@gmail.com> wrote: > > 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 >>>>>>>> iterator size >>>>>>>> >>>>>>>> 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: >>>>>>>> >>>>>>>> @op_iter.register is an almost hackish way to do it, it messes up with >>>>>>>> the class inheritance. We need something easier to use. >>>>>>>> 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. -- 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/CAKgW%3D6JVyjHNwgc9xmeyck57%3DH7Qsweou4XnDiXvqMy-8V95vg%40mail.gmail.com.
