On Thursday, September 24, 2015 at 8:22:53 PM UTC+2, Bill Page wrote: > > What answer should be expected when it is not possible to show that an > expression is zero? Would you expect that > > ex.is_zero() = not(ex.is_nonzero()) ? >
Yes, for constant expressions (i.e. not containing symbols) at the moment. With new code, yes for all expressions. > I suppose that I should expect True or False from > > bool(ex=0) > > and False in the case that it cannot be shown to be true. (assuming you meant bool(ex==0)) If you expect that then don't be surprised when innocent code behaves wrongly and uses unnecessary time, because the function that gets called will also get called with e.g. if (ex):... Having an explicit function for showing Truth(tm) will prevent this. > But I am not > so sure about is_... Do you expect only two possible outcomes and an > runtime error in the case of a failure to decide one or the other? > Having an explicit function for showing Truth(tm) will allow it to have three results: Yes/No/NotImplemented (Exceptions for things like complex x > 0). Ticket #17700 proposes tristate logic, SymPy has it too. The question is if we should call it is(). I just found that Maple too uses that name, so please voice any final objections. -- 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.
