Re: [sage-devel] Re: specification of __bool__

['Martin R' via sage-devel]

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  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. = 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
>>  
>> 
>> .
>>
>

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

Re: [sage-devel] Re: specification of __bool__

[David Roe]

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  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. = 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
> 
> .
>

-- 
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/CAChs6_mEktABgG8zMAjWZ-dG6%3D7CF%3DG-%3DcCbKUGz5cqcvo_D_A%40mail.gmail.com.

[sage-devel] Re: specification of __bool__

[Nils Bruin]

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. = 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.