Hi Francesco, yeah sure, I will proceed in that way. Thanks. On Monday, May 6, 2024 at 2:23:07 AM UTC+5:30 Francesco Bonazzi wrote:
> 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 samithkar...@gmail.com > 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 asme...@gmail.com 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 >>> <samithkar...@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+un...@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/88345f3e-63bc-4ffb-86b1-4ad9121adac5n%40googlegroups.com.
