Hi Aaron, Thank you for the reply, I would like to give it try. In-order to contribute to this project, I need to have a fork of this repository in somewhere (Sympy org or else). So If someone can help me with that I will try to contribute.
Best Regards, Samith Karunathilake. On Friday, May 3, 2024 at 2:54:28 AM UTC+5:30 [email protected] wrote: > 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 > <[email protected]> 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 > [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 > >>>>>>>> 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 > [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/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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/04106dfc-e555-4fff-91bb-a8bf0eee335dn%40googlegroups.com.
