Robert Bradshaw wrote: > On Jun 4, 2008, at 8:40 AM, Dan Christensen wrote: > >> "William Stein" <[EMAIL PROTECTED]> writes: >> >>> Sage Enhancement Proposal: Change comparisons that involve >>> elements of the symbolic ring to return True or False if both sides >>> of the symbolic comparison are constants and the comparison can >>> be definitely determined. >> I'm not sure what symbolic equations are currently used for, > > Stuff like > > sage: solve(x^2 == 5) > [x == -sqrt(5), x == sqrt(5)] > >> but >> this kind of special casing can cause problems. If I'm building >> up an equation using inputs that I don't control, my code may >> have unexpected problems if what it thinks is a symbolic equation >> turns into a boolean. > > I agree, think we should either always (my preference) or never > return a symbolic equation. "Can be definitely determined" could be > expensive too. > >> Maybe the heart of the matter is that we need a separate notation >> for symbolic equations vs. comparison. E.g. >> >> sage: 3 == pi >> False >> >> sage: 3 === pi >> 3 === pi >> >> sage: 1.2 == 1.3 >> False >> >> sage: 1.2 === 1.3 >> 1.2 === 1.3 >> >> Note that this gives you the ability to have symbolic equations >> when the components happen to not be symbolic. (Does this even >> make sense given the current set-up?) >> >> I'm not sure what to do if the user requests a comparison that >> sage can't easily determine: >> >> sage: sqrt(3) + sqrt(8) == sqrt(5) + pi >> >> One idea would be to return a symbolic equation >> >> sqrt(3) + sqrt(8) === sqrt(5) + pi >> >> but probably the best is to raise an exception: if my code is >> expecting a boolean, then a symbolic equation may confuse it. >> >> So my SEP would be that == always returns a boolean or raises >> an exception, and === always returns a symbolic equation. >> >> The notation === is of course a topic for discussion. If === >> is chosen, it would have to use the pre-processor. Is there >> another operator that would make sense? > > This was actually one of the original proposals. One would also have > to come up with operators for <, <=, >=, >, and !=. Also, in the > current system, it is easy to do > > sage: bool(3 == pi) > False > sage: if 3 == pi: > print "bad" > ....: > sage: >
Of course, bool(some equation) returning False does not necessarily mean that the two expressions are not equal; it only means that we couldn't prove them to be equal using some simple simplifications. From the docstring for _nonzero_ from equation.py (used to implement bool()): Return True if this (in)equality is definitely true. Return False if it is false or the algorithm for testing (in)equality is inconclusive. Thanks, Jason --~--~---------~--~----~------------~-------~--~----~ 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/sage-support URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
