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 <https://github.com/HPAC/matchpy/issues/69> suggests to create neutral or identity element, but for it to make a proper meaning in XML domain we need to make it as default value, likewise there are more things that we take into consideration if we need to support this for other types as well. Because somethings that supports in current version of matchpy would break when we add those functionalities.
On Monday, March 11, 2024 at 6:07:27 PM UTC+5:30 Francesco Bonazzi wrote: > 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 to use MatchPy's pattern matching and replacement algorithms > inside SymPy. So the main use case is the implementation of algorithms in > SymPy using MatchPy's algorithm. > > For example, can we implement an equation solver using MatchPy? There is a > basic example in the documentation of "matchpy_connector". > > Can MatchPy be modified and made more flexible so that we can avoid using > all evil tricks used in "matchpy_connector" to get it to work? > > Can MatchPy be rewritten in Rust for more efficiency? > > On Sunday, March 10, 2024 at 11:11:43 a.m. UTC+1 [email protected] > wrote: > >> 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 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 [email protected] >>> wrote: >>> >>>> Hi, >>>> Even though, I have engaged with few chats I thought to introduce me >>>> first. I am Samith Karunathilake, a third year undergraduate from >>>> University of Moratuwa, Sri Lanka. I have an interest on contributing for >>>> the Sympy for GSOC 2024. As for now I have baisc understanding about few >>>> areas, *sympy.series*, *matchpy_connector* and *parse_mathematica*. >>>> >>>> Here are the few methods that I identified about matchpy restructuring. >>>> Since, at the moment it uses an Expression node as the root node and we >>>> can redefine it and introduce some methods to check whether it is a >>>> instance of wildcard or an operation. >>>> Through that we can change the tree traversal method without bothering >>>> about the implementation of the Wild Card and Operations. >>>> If Francesco Bonazzi, or any potential mentor can give their idea on >>>> this thread, it would be much helpful. I will post more about this project >>>> as a reply for this thread. >>>> >>>> Thanks in advance for your collaboration. >>>> Samith Karunathilake. >>>> >>> -- 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/e25976d9-682f-4379-9001-961ab21be4a7n%40googlegroups.com.
