That sounds good, except as I noted at https://groups.google.com/forum/#!msg/sympy/42GdMJ9ssyM/swC6bHVunP8J, it's very important to build this around a framework of rewriting and decomposition. You want to be able solve, f(g(x)) = 0, where f is a polynomial and g is a lambertW (for example). You want the hints to be as simple as possible, and any complicated equations to be solvable by an application of possibly many hints. This is more complicated than what the ODE solver does.
Rewriting basically boils down to simplifying the matching portion of the hints. This is something that is not done very well in the ODE system, so I would only look there to see how it is lacking. You want each hint to match a simple pattern, and then have some set of rules on how to rewrite different expressions to that pattern mathematically, even if they don't match it structurally. I would take a look at the rules system used in the fu algorithm, and in the unify submodule. Also take a look at Francesco's pattern matching suggestions (search the mailing list and the wiki). Aaron Meurer On Sun, Mar 8, 2015 at 12:18 AM, AMiT Kumar <[email protected]> wrote: > Hi, > I was thinking, How about designing the solveset similiar > to the ODE Module . Something like hints system to classify solvers? > > Example: > > primaryhint = [ > "univariate", > "multivariate", > "single_eq", > "multiple_eq" > ] > > > subhints = [ > 'solve_linear_system' > 'linear_trig', > 'polynomial', > 'transcendental', > 'piecewise', > 'relational' > 'solve_lambertw' > 'miscellaneous' > ] > > > def classify_solver(f, symbols=None): > """ > Clasifies the input equation(s)/function(s) to solve for, into possible > hints such as linear, univariate, multivariate, etc. > """ > hints = [] > > # Methods to classify Equations > > def solveset(f, symbol=None): > > if eq_type == 'linear': > solve_linear(f, symbol) > > if eq_type == 'linear_system': > solve_linear_system(f, symbol) > > . > . > . and so on > > > > In that case we will be able to add new solvers, without messing with > the others, and we will have a more robust and flexible framework > which will be easy to extend. > > I think, building a robust framework, which felicitates further > development, worth much more than adding new solvers. > > Thoughts from the community are invited. > > AMiT Kumar > > -- > 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 post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/sympy. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/5b7393ef-7d4d-46f9-bfcd-dbbeb38639c4%40googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. -- 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 post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6L9SzPBRoiMs3FNRBDka-r_KZ4PrnQ%3DL-0ibLffzoDHqw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
