I tend to be in favor of the True/False/raise Exception model for testing equality, but has anybody looked into what would be involved to transition the Sage ilbrary? I imagine we would have to adapt a lot of code.
On Wednesday, July 31, 2013 5:33:30 AM UTC-4, kro...@uni-math.gwdg.de wrote: > > Am Sonntag, 13. April 2008 02:39:24 UTC+2 schrieb William Stein: > > On Sat, Apr 12, 2008 at 5:33 PM, Carl Witty <cw...@newtonlabs.com> > wrote: > > > > > > On Apr 12, 8:58 am, Jason Grout <jason-s...@creativetrax.com> wrote: > > > > Carl Witty wrote: > > > > > On Apr 10, 1:41 am, Simon King <k...@mathematik.uni-jena.de> > wrote: > > > > >> On Apr 10, 4:18 am, Carl Witty <cwi...@newtonlabs.com> wrote: > > > > > > > > >>> I like the "raise an exception" behavior, because it would > eliminate > > > > >>> questions asking why form1 and form2 below are different (from > this > > > > >>> sage-support threadhttp:// > groups.google.com/group/sage-support/browse_thread/thread/79d0...). > > > > >>> (I have seen this exact problem at least twice on > sage-support.) What > > > > >>> do you think? > > > > >> I guess what i suggest wouldn't solve the plot-issue. However, i > think > > > > >> if one doesn't know whether an inequality holds, or if the > inequality > > > > >> simply makes no sense (such as in the case of an unordered > field) then > > > > >> bool() should neither raise an exception nor return False but > return > > > > >> None. I think it is much simpler to have > > > > > > > The reason why I eventually decided that throwing an exception was > > > > unpythonic was that I could not find a single case of current python > > > > code which did that. Actually, the one reference I did find was a > > > > bugfix to a project (I think SQLAlchemy), in which they changed > > > > __nonzero__ to not raise an exception since it was inconsistent with > > > > other behavior. > > > > > > > > That, and the fact that Python by default returns True for objects > > > > instead of raising exceptions, tells me that raising exceptions > would > > > > also raise an exceptional number of eyebrows and probably voices > too. > > > > > > I agree that raising an exception is somewhat unpythonic, but I don't > > > think that's an automatic veto on the idea. Sage does lots of > > > unpythonic stuff already, and I think we should at least consider > > > adding one more unpythonic behavior in this case. > > > > > > I still think that most of the times people write "if x > 0:", they > > > will be implicitly wanting an unevaluated, symbolic conditional that > > > we can't automatically provide; in these cases, I think raising an > > > exception is much better than silently giving a result quite different > > > than what's desired. > > > > > > For the few cases where people actually understand the issues (and the > > > issues are complicated, involving two very different kinds of > > > variables and two very different kinds of evaluation), and write "if x > > > > 0:" wanting the current behavior, an exception is slightly worse > > > than the current behavior; but if the exception points at a simple > > > workaround (by having "Use the .known_true() method to evaluate > > > unknown conditions to False" as part of the exception text) then the > > > cost is very small. > > > > > > So according to this analysis, raising the exception is a large > > > benefit (doesn't silently give the wrong answer) for a larger number > > > of novice users, and a small cost for a smaller number of expert > > > users. If this is correct, then I think we should raise the > > > exception. > > > > > > > I vote +1 to Carl's proposal. > > > > William > > Dear sagemath-developers, > > > the issue with unexpected behaviour of bool(SymbolicExpression) > seems still unresolved (at least in versions <= 5.8); > see http://ask.sagemath.org/question/2853/testing-inequalities-in-sage > > I vote for returning an exception in case the algorithm cannot decide if > the expression is True or False; > alternatively ( in my opinion ) bool() should NOT be applicable to > symbolic expressions for which a natural answer is at least tri-state, even > if it breaks a lot of code. > > > Best, > > > Jack > > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
