It seems attractive that for numerical types, bool(a) gives that same result as "not(a==0)", which would hopefully be the same as "a!=0".
It is definitely the case that O(t^5) == 0 is a lot more useful for computations. For instance, with that in place, Gaussian elimination will actually sort-of work on a matrix of power series with plenty of precision (it will work quite badly if you don't implement an appropriate pivoting strategy, though). If O(t^5) != 0 , basically nothing works and you end up with a numerical type that is virtually useless, except for the things purpose-implemented for it. So for that reason, equal-to-zero testing pretty much has to assume that enough precision is available to distinguish elements that you'll be encountering in your particular computation. You'll only be proving that things are not equal that way: you'll just get evidence things may be equal, unless you establish lower bounds on distance between elements that are not equal. Your examples for interval arithmetic have their roots more in floating point, where equality testing is more generally accepted to be useless, but I would say that has a different pedigree than p-adic and power series, non-archimedean metrics, where a question about a power series .... + O(t^5) is much more clearly a question about an element of k[t]/(t^5), where equality has a very well-defined meaning. Whether "a != 0" should be basically the same as "bool(a)" ... python tradition says it should. If it's not, then I'd say bool(a) is pretty much useless anyway. I don't think the python habit of replacing every "if a !=0 :" by "if a:" is a good one, but I acknowledge the habit is widespread. So laying mines by breaking its equivalence is a bad idea. On Tuesday, 27 September 2022 at 05:00:00 UTC-7 axio...@yahoo.de wrote: > I think that x.__bool__ should return True only if x is *known* to be zero. > > I have three docstrings that support this view: > > rings/real_mpfi.pyx\03905: def __bool__(self): > rings/real_mpfi.pyx\03906- """ > rings/real_mpfi.pyx\03907- Return ``True`` if ``self`` is not known > to be exactly zero. > rings/real_mpfi.pyx\03908- > -- > rings/complex_interval.pyx\01495: def __bool__(self): > rings/complex_interval.pyx\01496- """ > rings/complex_interval.pyx\01497- Return ``True`` if ``self`` is > not known to be exactly zero. > rings/complex_interval.pyx\01498- > -- > symbolic/expression.pyx\03310: def __bool__(self): > symbolic/expression.pyx\03311- """ > symbolic/expression.pyx\03312- Return True unless this symbolic > expression can be shown by Sage > symbolic/expression.pyx\03313- to be zero. Note that deciding if > an expression is zero is > > and I have not found a docstring contradicting this point of view. > However, the behaviour of (fixed precision) power series is different: > > sage: R.<t> = QQ[[]] > sage: f = t.add_bigoh(5) - t > sage: f > O(t^5) > sage: not f > True > > I think that this is a bug. > > One implication is, as noticed by Chris Wuthrich, that the product "x * y" > is not necessarily zero, even if "not x" gives True. > > Before trying to create a branch, I'd like to hear other opinions. > > Martin > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/73d3e6ae-f431-466e-a8c4-34ebc59f9e77n%40googlegroups.com.
