Is there a pull request with the code associated with this, or is it only in the Binder for now?
The end-user API looks good to me. I think there may be some technical questions on the specifics on the implementation, but those wouldn't affect how things look at the end. The only thing that stands out to me as a possible wart is that there are two identical attributes for swapping an equation, .reversed and .swap. I would just pick one. My preference would be for the shorter one just because it's easier to type. I would also remove the "check" option. There needs to be a clear distinction between Eq(), which is a boolean (i.e., it is either True or False, though it's exact value may be symbolic), and Eqn() which represents a manipulatable left-hand side and right-hand side. Eqn() shouldn't produce an error if the sides are unequal. The whole point of Eqn should be to be able to take something like Eqn(x, x + 1) and manipulate it in a way that shows that it is inconsistent. For example, suppose you have a set of equation objects representing a system of linear equations. You could directly manipulate them using the elementary row operations to solve the system (https://en.wikipedia.org/wiki/Gaussian_elimination#Row_operations). The system is inconsistent if and only if the equation 1 = 0 can be produced. If this resulted in an error, then it would interrupt the flow of solving the system. The whole point of Eqn() should be to represent equations and manipulate them in a way that one can determine if they do or don't have solutions. At best, there could be a method on Eqn() that tries to determine if the equation has zero solutions (e.g., as_Boolean() or solve()). Another potential gotcha point is that you currently allow performing any function to both sides of an equation. This includes functions that aren't one-to-one, meaning doing so can introduce solutions. I don't think this is something that should be disallowed, but it should perhaps be mentioned in the documentation. This is also a "gotcha" in standard algebra, it's just worth noting that we don't do anything to try to guard against it. Rather, Eqn() just uses the simple design where Eqn + Eqn just adds corresponding sides, and Eqn() + expr adds expr to both sides (and the same if you replace + with any function or operation). Something that is missing from this API is substitution. We already decided that subs() shouldn't work with the boolean Eq(), but I think it makes sense for Eqn() (see https://github.com/sympy/sympy/issues/14741). This is actually another reason to not consider something like Eqn(x, x + 1) as invalid. As a boolean equality, it is meaningless, but as input to subs() it makes sense. A more interesting case is substituting one equation in another. This is important if we think of Eqn() as an object that can be used to manipulate equalities in a way that would typically be done when solving a system of equations. If you have x + y = 4 and x*y = 4, the typical way to solve the system by hand would be to isolate one of the variables in one of the equations, and substitute it in the other. Something like eq1 = Eqn(x + y, 4) eq2 = Eqn(x*y, 4) eq1 = eq1 - y # subtract y from both sides, isolating x eq2 = eq2.subs(eq1) # This produces Eqn((4 - y)*y, 4) solve(eq2) Isolation is also maybe something that could be easier too. Should solve(Eqn()) always return another Eqn (or list of Eqn)? One could also consider how one would solve eq2 by hand. Should there be a method to split products into cases, like Eqn(A*B, 0) -> [Eqn(A, 0), Eqn(B, 0)]? Aaron Meurer On Wed, Jan 6, 2021 at 8:04 PM gu...@uwosh.edu <gu...@uwosh.edu> wrote: > > I have developed a SymPy tool that allows manipulation of equations (two > expression equal to each other, e.g. `a*b = c/d`) using as close to standard > mathematical notation as I could manage. This is primarily meant for > interactive use when doing manual algebra, but has some potential uses as a > backend for automatic symbolic manipulations. > > While working to make it possible to incorporate this tool into the sympy > codebase some questions have arisen about how this would be used and thus the > best way to interface it with sympy. Therefore we need a broader community > discussion of this tool. > > Anybody can try this tool interactively by following this mybinder.org link: > https://mybinder.org/v2/gh/gutow/Algebra_with_Sympy.git/master. The > demonstrations of the capabilities are in the Jupyter notebook `Demonstration > of equation class.ipynb`. > > We are interested in knowing if people find any of the behavior odd and why. > In particular we are not sure about the best behavior for differentiation and > integration, so please look at those sections carefully. We could also use > input on operations that you would like to work that do not and how they > should behave. > > Please reply to this discussion thread. > > Thank you, > Jonathan > > -- > 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 sympy+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/2fc7dc45-dd5f-4186-a1a3-f49edcb7c64dn%40googlegroups.com. -- 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 sympy+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6LQVb_n%3DjPXeaAztOyASJPEEO%2BCOeK3j6FmBPVHWp0WJw%40mail.gmail.com.
