OK. On Tuesday, 27 September 2022 at 17:50:04 UTC+2 David Roe wrote:
> Nils put it well; please don't change __bool__ for p-adic and power > series. It should be compatible with equality testing. > David > > On Tue, Sep 27, 2022 at 11:44 AM Nils Bruin <nbr...@sfu.ca> wrote: > >> 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+...@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 >> >> <https://groups.google.com/d/msgid/sage-devel/73d3e6ae-f431-466e-a8c4-34ebc59f9e77n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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/efd55988-060a-4e4d-87b5-1beeaeda2f1dn%40googlegroups.com.