Comment #26 on issue 51 by asmeurer: RootOf for polynomial equations
http://code.google.com/p/sympy/issues/detail?id=51

I'm convinced that returning simple roots is the way to go (it's handy in certain situations)

Well, you could always have a doit() method to return them if it remains unevaluated always, but never if doesn't. Consider that if someone is explicitly using RootOf instead of solve() or roots(), that means that they want an unevaluated form. In my experience, making unevaluated classes remain unevaluated by default even in the most trivial cases is always beneficial.

So maybe it should be unevaluated by default and there should be a RootOf.trivial_roots() method that gives the easy cases that it now does automatically.

I think that I will extend RootOf syntax to allow:

OK, this sounds good. As long as there aren't any inconsistencies (i.e., potential confusion) in the syntax, I think it is a good idea.

If we allow RootOf(poly, x, index) syntax then it will be tempting to use RootOf for things like RootOf(exp(abs(x)) - 1). I'm not sure if this should be allowed, because right now, RootOf has very nice properties, e.g. symbolic root isolation, which we won't be able to achieve in non-polynomial cases.

I think it might actually be useful to allow that. You would have to make RootOf(exp(abs(x)) - 1) raise NotImplementedError if you try to call evalf() or most other methods (actually, in that particular case it might be able to do something if solve() became smart enough can handle that equation). The reason is that sometimes you just want a way to symbolically implicitly represent the root or roots of an equation, even if there is nothing else really that you can do with it.

Here's an example: right now, our solve() is not very good for transcendental functions. Suppose that, in the course of trying to do something else, a solve() call is made that can't do it. If solve() were able to return RootOf, maybe the routine could continue. Then, the final result would have a RootOf of whatever equation it couldn't do (say exp(abs(x)) - 1). Then, at this point, the user could take this equation, pass it to the solve function of some other CAS (like Wolfram Alpha or Maple, or maybe they are using Sage and have a whole toolbox at their disposal). Then, upon obtaining a closed form solution that SymPy couldn't find, they can subs in the solution (in this case, x = 0), into the equation.

The way it is now, they have to stop everything when solve() fails and do this step, then manually enter the solution at that point, which could be annoying if they routine is run as a script (as opposed to step by step in the isympy interpreter).

Also, the point I was trying to make was that if we decide to add (require) the RootOf(poly, x, index) syntax in the future, it will break API with the current RootOf(poly, index) syntax. Better to require x from the start, even if right now it is not necessary.

--
You received this message because you are subscribed to the Google Groups 
"sympy-issues" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/sympy-issues?hl=en.

Reply via email to