>I changed the code to return an exception if the truth value is unknown and ran `sage -testall`.
Did you upload the patch to somewhere? Where this change has to be made? > I might be willing to fix these tests when I have time. It seems that nothing happens for more than a year, so maybe someone else has time to fix this? I opened a ticket : http://trac.sagemath.org/ticket/17700 Jakob Am Samstag, 10. August 2013 00:04:32 UTC+2 schrieb Eviatar: > > I changed the code to return an exception if the truth value is unknown > and ran `sage -testall`. Here are the results: > > sage -t devel/sage/sage/tensor/differential_form_element.py # 43 doctests > failed > sage -t devel/sage/sage/tensor/differential_forms.py # 1 doctest failed > > sage -t devel/sage/sage/calculus/tests.py # 4 doctests failed > > sage -t devel/sage/sage/calculus/calculus.py # 10 doctests failed > > sage -t devel/sage/sage/calculus/desolvers.py # 8 doctests failed > > sage -t devel/sage/sage/calculus/wester.py # 3 doctests failed > > sage -t devel/sage/sage/symbolic/assumptions.py # 8 doctests failed > > sage -t devel/sage/sage/symbolic/expression.pyx # Killed due to > segmentation fault > sage -t devel/sage/sage/symbolic/units.py # Killed due to segmentation > fault > sage -t devel/sage/sage/symbolic/relation.py # 2 doctests failed > > sage -t devel/sage/sage/matrix/matrix_symbolic_dense.pyx # 2 doctests > failed > sage -t devel/sage/sage/doctest/forker.py # 1 doctest failed > > sage -t devel/sage/sage/misc/functional.py # 2 doctests failed > > sage -t devel/sage/sage/misc/cachefunc.pyx # 1 doctest failed > > sage -t devel/sage/sage/combinat/tutorial.py # 9 doctests failed > > sage -t devel/sage/sage/tests/french_book/recequadiff.py # 25 doctests > failed > > Many of the failed tests are due to dependence on variables which would > have been assigned in previous tests, but failed due to the exception. I > might be willing to fix these tests when I have time. > > On Friday, 2 August 2013 07:04:42 UTC-7, Volker Braun wrote: >> >> 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/d/optout.
