Please consider adding numbers.Boolean
I'm just curious if there was a reason why Boolean was omitted from the numeric tower in the numbers library? It seems that builtins.bool and numpy.bool_ would both be elements of Boolean, and Boolean itself would be Integral? Best, Neil
On 22/06/20 12:19 pm, Neil Girdhar wrote:
I'm just curious if there was a reason why Boolean was omitted from the numeric tower in the numbers library?
Python's bool type is a subclass of int for historical reasons, not because it's conceptually a numeric type. Doing arithmetic on it doesn't really make mathematical sense. -- Greg
I disagree that doing arithmetic on boolean variables doesn't make sense. Indicator variables which take a value of either zero are one are extremely common. Dirac or Kronecker delta functions are also examples of functions where it arithmetically makes sense to talk about values in the boolean domain. Of course that does mean that you define True as 1 and False as 0, but that is a very standard convention and it is the case in Python. I don't have a strong opinion on the proposal itself, but saying "arithmetic on booleans doesn't doesn't make mathematical sense" is False. On Mon, Jun 22, 2020 at 5:08 AM Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
-- -Dr. Jon Crall (him)
[Neil Girdhar]
It seems that builtins.bool and numpy.bool_ would both be elements of Boolean
I'd be wary of trying to abstract over `bool` and `numpy.bool_`. There are some fundamental differences: - `bool` subclasses `int`; `numpy.bool_` is not a subclass of any integer type - moreover, `numpy.bool_` isn't considered integer-like. It _does_ currently support `__index__`, but that support is deprecated, so at some point in the future a `numpy.bool_` may not be usable in many of the contexts that a Python bool is. (cf https://bugs.python.org/issue37980) - some bitwise operations behave differently: `~False` is not equal to `~np.False_`, and similarly for `True` What's the motivation for this? Is this intended primarily for use in type annotations, or did you have some other use in mind? -- Mark
On Mon, Jun 22, 2020 at 10:19 AM Serhiy Storchaka <storchaka@gmail.com> wrote:
I'm highly ambivalent about Python's model of "Truthiness" -- it's really convenient often, but also gives me a lack of control. So I think it would be helpful, in static type checking cases in particular to say something HAS to be a Bool, and only a Bool. And in that context, I don't think I'd want allow integers. Also, in the reverse, I would wan't folks to be able to use Bools when an integer or other number is expected. So in short: no, Bool should not be considered a Numeric "type" -CHB
-- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
On 22/06/20 12:19 pm, Neil Girdhar wrote:
I'm just curious if there was a reason why Boolean was omitted from the numeric tower in the numbers library?
Python's bool type is a subclass of int for historical reasons, not because it's conceptually a numeric type. Doing arithmetic on it doesn't really make mathematical sense. -- Greg
I disagree that doing arithmetic on boolean variables doesn't make sense. Indicator variables which take a value of either zero are one are extremely common. Dirac or Kronecker delta functions are also examples of functions where it arithmetically makes sense to talk about values in the boolean domain. Of course that does mean that you define True as 1 and False as 0, but that is a very standard convention and it is the case in Python. I don't have a strong opinion on the proposal itself, but saying "arithmetic on booleans doesn't doesn't make mathematical sense" is False. On Mon, Jun 22, 2020 at 5:08 AM Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
-- -Dr. Jon Crall (him)
[Neil Girdhar]
It seems that builtins.bool and numpy.bool_ would both be elements of Boolean
I'd be wary of trying to abstract over `bool` and `numpy.bool_`. There are some fundamental differences: - `bool` subclasses `int`; `numpy.bool_` is not a subclass of any integer type - moreover, `numpy.bool_` isn't considered integer-like. It _does_ currently support `__index__`, but that support is deprecated, so at some point in the future a `numpy.bool_` may not be usable in many of the contexts that a Python bool is. (cf https://bugs.python.org/issue37980) - some bitwise operations behave differently: `~False` is not equal to `~np.False_`, and similarly for `True` What's the motivation for this? Is this intended primarily for use in type annotations, or did you have some other use in mind? -- Mark
On Mon, Jun 22, 2020 at 10:19 AM Serhiy Storchaka <storchaka@gmail.com> wrote:
I'm highly ambivalent about Python's model of "Truthiness" -- it's really convenient often, but also gives me a lack of control. So I think it would be helpful, in static type checking cases in particular to say something HAS to be a Bool, and only a Bool. And in that context, I don't think I'd want allow integers. Also, in the reverse, I would wan't folks to be able to use Bools when an integer or other number is expected. So in short: no, Bool should not be considered a Numeric "type" -CHB
-- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
participants (7)
-
Christopher Barker -
Eric V. Smith -
Greg Ewing -
Jonathan Crall -
Mark Dickinson -
Neil Girdhar -
Serhiy Storchaka