Worth pointing out something here. We are talking about the internal API. The external, user-level API will be to just use solve, with integer Symbols. The user-level API needs to be able to handle any kind of parametrized solution, like solve(cos(x)) or solve(underdetermined_linear_system) and is what really requires the thought. I hope that we can solve the issue, though, as otherwise we won't be able to integrate Thilina's solvers into solve().
Aaron Meurer Sent from my iPad On Jun 20, 2013, at 3:23 AM, Stefan Krastanov <[email protected]> wrote: > Unnamed dummies print with some numeric index, right? > > Anyway, I very strongly feel that arguments about printing should be > considered only when there are no other concerns: SymPy is not a > typesetting library. > > The other concerns: > > - assumptions: If we were going to solve one simple equation, yes it > might be sufficient to mention assumptions only in the docstring, but > in a general api this will fail: What about intersections of some > algebraic curves where the parameter can take only certain values, or > (in other solvers) solutions to differential or functional equations > where there is something like a bifurcation and completely different > solutions arise for different values of a parameter (double roots in > the characteristic equation for instance)? > > - Providing the appropriate number of parameters as a keyword will > require from the user to actually study the equation and deduce how > many parameters are needed. While I am always for forcing the user to > think about what he is writing, this is a bit too far: the whole idea > of the solver is that the user should not solve the equation by > himself. We have an algorithm to classify the equations, we should > just use it. > > > I am ok with the idea of providing an optional keyword argument for > the parameter name, but this should just be an afterthought, not the > main way to work with the api. > > On 20 June 2013 08:40, Chris Smith <[email protected]> wrote: >> Dummy is insufficient to give a visually distinguished symbol as I >> indicated. Getting a results that looks like `{x: _t + _t + 2}`. But >> actually, if I'm not mistaken the coefficients will always be integers so at >> worst one might get {_t: _t + 2} where the dict key is the original Symbol >> and the `_t` in the value of the dict, the dummy parameter. >> >> -- >> 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. >> For more options, visit https://groups.google.com/groups/opt_out. > > -- > 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. > For more options, visit https://groups.google.com/groups/opt_out. > > -- 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. For more options, visit https://groups.google.com/groups/opt_out.
