David, Can you explain further what you are thinking in terms of dangerous functions? At present `Equations` supports doing things to only one side through syntax like `.applylhs(method, *args)` and less generally `.dorhs.method()`. So I think that `Equation` may already support what you are suggesting. Is that correct? Otherwise except in the cases of differentiation and integration operations are always applied symmetrically to both sides.
Thanks for the comments. Jonathan On Saturday, January 9, 2021 at 9:24:02 AM UTC-6 [email protected] wrote: > On 09/01/2021 11:57, S.Y. Lee wrote: > > I have previously questioned that Wolfram have a == b -> a/c == b/c > transformation in conditional expression format > https://reference.wolfram.com/language/ref/DivideSides.html and why you > were not attempting to implement same like this, > But now I'd may agree on that if we treat such examples as polynomial > algebra, those transformation can make mathematical sense without > connection to the assumptions behind. > And I believe that in this sense, differentiation and integration can > similarly avoid such hoax without treatment of assumptions. > > But now I have an another question if the manipulation works in > algebraically robust way, > For example, we have lots of pitfalls of expression tree manipulation that > some simple examples like "x / x" work, > but we soon end up with some more complicated examples like " > exp(x+1)/exp(1)" doesn't work robustly, > and the only way to cope with them are appending > .expand().cancel().together().simplify(), ... to the tail which is pretty > much black-boxed and not robust at all. > > So this is one of the problem that I'm skeptical about how they can be > used as a backend for automatic symbolic manipulations, rather than some > convenience tools for end users. > And for such purposes I believe that we rather have to make object like > PolyEquation. > > I suppose I think the problem is that many users DO use SymPy as a tool to > do calculations - not as something to build into something else. As you > acknowledge, such convenience functions are almost essential to make good > use of an equation class interactively, even though they can produce > mistakes when wrongly used (as can subs). > > One possibility might be to place 'dangerous' functions, such as > DivideSides, in a submodule of SymPy so that they are only loaded if the > user, or the system builder, deems it appropriate - very much as users can > choose to import the symbols from sympy.abc at their discretion. > > Obviously such functions would not be used by default by simplify if it > were applied to equation objects. > > David > > > -- 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/7aaee06e-c37a-4d84-b71d-eb081e5c6840n%40googlegroups.com.
