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.dewrote:
>>
>> 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.
