Re: [sympy] Re: Enhancing the flexibility of MatchPy

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

Re: [sympy] Re: Enhancing the flexibility of MatchPy

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

Re: [sympy] Re: Enhancing the flexibility of MatchPy

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

Re: [sympy] Re: Enhancing the flexibility of MatchPy

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

Re: [sympy] Re: Enhancing the flexibility of MatchPy

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

Re: [sympy] Re: Enhancing the flexibility of MatchPy

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

Re: [sympy] Re: Enhancing the flexibility of MatchPy

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 

Re: [sympy] Re: Enhancing the flexibility of MatchPy

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

Re: [sympy] Re: Enhancing the flexibility of MatchPy

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

Re: [sympy] Re: Enhancing the flexibility of MatchPy

No, no parsers are needed. Just a tree traversal for-loop. It's already implemented: - iterator - iterator size

Re: [sympy] Re: Enhancing the flexibility of MatchPy

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,

Re: [sympy] Re: Enhancing the flexibility of MatchPy

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

Re: [sympy] Re: Enhancing the flexibility of MatchPy

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__

Re: [sympy] Re: Enhancing the flexibility of MatchPy

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

[sympy] Re: Enhancing the flexibility of MatchPy

On Wednesday, March 13, 2024 at 1:29:37 a.m. UTC+1 samithkar...@gmail.com wrote: Hi, If we are maintianing matchpy as our own repository, Is it okay for us to make the matchpy elements in more integrated way to sympy, or still we need to support the every functionalities that matchpy gave

Re: [sympy] Re: Enhancing the flexibility of MatchPy

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. If making MatchPy more SymPy specific eases the development burden, we should do that, especially if we are going to fork it anyway. I

[sympy] Re: Enhancing the flexibility of MatchPy

Hi, If we are maintianing matchpy as our own repository, Is it okay for us to make the matchpy elements in more integrated way to sympy, or still we need to support the every functionalities that matchpy gave earlier. As an example, issue 69 suggests

[sympy] Re: Enhancing the flexibility of MatchPy

The main issue is that we don't control the MatchPy repository. It's owned by a research center. Unfortunately they don't appear to be active anymore, so I guess we'll probably have to fork the project. Regarding SymPy, our aim is to improve the integration between MatchPy and SymPy in order

[sympy] Re: Enhancing the flexibility of MatchPy

Hi Francesco, Thank you for the reply. How should I progress in this project? I have several issues encountered when I am going through the matchpy repository, where would I raise those issues. On Wednesday, March 6, 2024 at 3:49:09 PM UTC+5:30 Francesco Bonazzi wrote: > The idea that I have

[sympy] Re: Enhancing the flexibility of MatchPy

The idea that I have in mind requires forking the MatchPy library. If we can find a way to modify the tree-traversal algorithms in MatchPy in order not to depend on type checks, we will make MatchPy's integration into SymPy much easier. On Wednesday, March 6, 2024 at 1:17:17 a.m. UTC+1