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.

Reply via email to