Do you mean forking MatchPy? I would suggest by creating a personal fork of the project. I would not create a fork of MatchPy on SymPy's space unless we're really sure about continuing the development of MatchPy.
On Saturday, May 4, 2024 at 4:18:32 a.m. UTC+2 [email protected] wrote: > 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/eb4d52d9-ab41-4b56-aafb-e9848f08e2b4n%40googlegroups.com.
