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.
