Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #110282 > unrolled thread

Operator Precedence/Boolean Logic

Back to article view | Back to comp.lang.python

Contents

  Operator Precedence/Boolean Logic Elizabeth Weiss <cake240@gmail.com> - 2016-06-21 20:40 -0700
    Re: Operator Precedence/Boolean Logic Ben Finney <ben+python@benfinney.id.au> - 2016-06-22 13:59 +1000
      Re: Operator Precedence/Boolean Logic Elizabeth Weiss <cake240@gmail.com> - 2016-06-22 21:19 -0700
      Re: Operator Precedence/Boolean Logic Elizabeth Weiss <cake240@gmail.com> - 2016-06-22 21:20 -0700
    Re: Operator Precedence/Boolean Logic Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-06-22 16:02 +1000
    Re: Operator Precedence/Boolean Logic Christian Gollwitzer <auriocus@gmx.de> - 2016-06-22 08:26 +0200
      Re: Operator Precedence/Boolean Logic Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-06-22 10:14 +0300
        Re: Operator Precedence/Boolean Logic Elizabeth Weiss <cake240@gmail.com> - 2016-06-22 21:21 -0700
    Re: Operator Precedence/Boolean Logic Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-22 00:42 -0700
      Re: Operator Precedence/Boolean Logic Larry Hudson <orgnut@yahoo.com> - 2016-06-22 20:12 -0700
        Re: Operator Precedence/Boolean Logic Steven D'Aprano <steve@pearwood.info> - 2016-06-23 13:59 +1000
          Re: Operator Precedence/Boolean Logic Elizabeth Weiss <cake240@gmail.com> - 2016-06-22 21:23 -0700
          Re: Operator Precedence/Boolean Logic Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-23 09:58 +0200
            Re: Operator Precedence/Boolean Logic Marko Rauhamaa <marko@pacujo.net> - 2016-06-23 11:16 +0300
              Re: Operator Precedence/Boolean Logic Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-23 01:53 -0700
                Re: Operator Precedence/Boolean Logic Marko Rauhamaa <marko@pacujo.net> - 2016-06-23 12:10 +0300
                  Re: Operator Precedence/Boolean Logic Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-23 11:27 +0200
                    Re: Operator Precedence/Boolean Logic Marko Rauhamaa <marko@pacujo.net> - 2016-06-23 12:53 +0300
                      Re: Operator Precedence/Boolean Logic Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-23 12:54 +0200
                        Re: Operator Precedence/Boolean Logic Marko Rauhamaa <marko@pacujo.net> - 2016-06-23 13:59 +0300
                          Re: Operator Precedence/Boolean Logic Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-23 13:15 +0200
                            Re: Operator Precedence/Boolean Logic Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-06-23 15:05 +0300
                              Re: Operator Precedence/Boolean Logic Chris Angelico <rosuav@gmail.com> - 2016-06-23 22:13 +1000
                  Re: Operator Precedence/Boolean Logic Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-23 02:44 -0700
                    Re: Operator Precedence/Boolean Logic Marko Rauhamaa <marko@pacujo.net> - 2016-06-23 12:57 +0300
                      Re: Operator Precedence/Boolean Logic Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-24 22:38 -0700
                        Re: Operator Precedence/Boolean Logic Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-06-25 09:46 +0300
              Re: Operator Precedence/Boolean Logic Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-23 11:01 +0200
            Re: Operator Precedence/Boolean Logic Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-06-23 19:39 +1000
              Re: Operator Precedence/Boolean Logic Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-23 12:21 +0200
                Re: Operator Precedence/Boolean Logic Steven D'Aprano <steve@pearwood.info> - 2016-06-23 22:37 +1000
                  Re: Operator Precedence/Boolean Logic Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-23 15:24 +0200
                  Re: Operator Precedence/Boolean Logic Random832 <random832@fastmail.com> - 2016-06-23 09:26 -0400
                    Re: Operator Precedence/Boolean Logic Steven D'Aprano <steve@pearwood.info> - 2016-06-24 02:43 +1000
                  Re: Operator Precedence/Boolean Logic Chris Angelico <rosuav@gmail.com> - 2016-06-24 01:49 +1000
          Re: Operator Precedence/Boolean Logic Marko Rauhamaa <marko@pacujo.net> - 2016-06-25 11:56 +0300
        Re: Operator Precedence/Boolean Logic Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-22 21:47 -0700
          Re: Operator Precedence/Boolean Logic Rustom Mody <rustompmody@gmail.com> - 2016-06-22 22:00 -0700
          Re: Operator Precedence/Boolean Logic Andreas Röhler <andreas.roehler@online.de> - 2016-06-23 08:34 +0200
            Re: Operator Precedence/Boolean Logic Marko Rauhamaa <marko@pacujo.net> - 2016-06-23 09:46 +0300
            Re: Operator Precedence/Boolean Logic Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-06-23 17:05 +1000
              Re: Operator Precedence/Boolean Logic Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-23 10:17 +0200
                Re: Operator Precedence/Boolean Logic Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-06-23 18:48 +1000
                  Re: Operator Precedence/Boolean Logic Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-23 11:23 +0200
                  Re: Operator Precedence/Boolean Logic Chris Angelico <rosuav@gmail.com> - 2016-06-23 21:45 +1000
                  Re: Operator Precedence/Boolean Logic Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-23 14:08 +0200
                  Re: Operator Precedence/Boolean Logic Andreas Röhler <andreas.roehler@online.de> - 2016-06-23 14:22 +0200
              Re: Operator Precedence/Boolean Logic Andreas Röhler <andreas.roehler@online.de> - 2016-06-23 10:23 +0200
              Re: Operator Precedence/Boolean Logic Andreas Röhler <andreas.roehler@online.de> - 2016-06-23 10:32 +0200
                Re: Operator Precedence/Boolean Logic Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-06-23 19:17 +1000
                  Re: Operator Precedence/Boolean Logic Marko Rauhamaa <marko@pacujo.net> - 2016-06-23 12:46 +0300
                    Re: Operator Precedence/Boolean Logic Andreas Röhler <andreas.roehler@online.de> - 2016-06-23 12:19 +0200
                    Re: Operator Precedence/Boolean Logic Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-26 11:01 +1200
                      Re: Operator Precedence/Boolean Logic Rustom Mody <rustompmody@gmail.com> - 2016-06-29 03:21 -0700
                        Re: Operator Precedence/Boolean Logic Chris Angelico <rosuav@gmail.com> - 2016-06-29 21:06 +1000
                        Re: Operator Precedence/Boolean Logic Steven D'Aprano <steve@pearwood.info> - 2016-06-29 23:08 +1000
                          Re: Operator Precedence/Boolean Logic Rustom Mody <rustompmody@gmail.com> - 2016-06-29 06:30 -0700
                            Re: Operator Precedence/Boolean Logic Steven D'Aprano <steve@pearwood.info> - 2016-06-30 09:40 +1000
                              Re: Operator Precedence/Boolean Logic Rustom Mody <rustompmody@gmail.com> - 2016-06-30 09:01 -0700
                                Re: Operator Precedence/Boolean Logic Steven D'Aprano <steve@pearwood.info> - 2016-07-01 03:22 +1000
                                  Re: Operator Precedence/Boolean Logic Rustom Mody <rustompmody@gmail.com> - 2016-07-15 22:48 -0700
                                    Re: Operator Precedence/Boolean Logic Rustom Mody <rustompmody@gmail.com> - 2016-07-15 22:58 -0700
                                      Re: Operator Precedence/Boolean Logic Steven D'Aprano <steve@pearwood.info> - 2016-07-16 19:14 +1000
                                    Re: Operator Precedence/Boolean Logic Steven D'Aprano <steve@pearwood.info> - 2016-07-16 20:16 +1000
                                      Re: Operator Precedence/Boolean Logic Chris Angelico <rosuav@gmail.com> - 2016-07-16 20:46 +1000
                                        Re: Operator Precedence/Boolean Logic Steven D'Aprano <steve@pearwood.info> - 2016-07-16 21:02 +1000
                                          Re: Operator Precedence/Boolean Logic Chris Angelico <rosuav@gmail.com> - 2016-07-17 00:26 +1000
                                        Re: Operator Precedence/Boolean Logic Rustom Mody <rustompmody@gmail.com> - 2016-07-16 05:33 -0700
                                          Re: Operator Precedence/Boolean Logic Steven D'Aprano <steve@pearwood.info> - 2016-07-17 02:27 +1000
                                            Re: Operator Precedence/Boolean Logic MRAB <python@mrabarnett.plus.com> - 2016-07-16 17:58 +0100
                                              Re: Operator Precedence/Boolean Logic Rustom Mody <rustompmody@gmail.com> - 2016-07-16 20:43 -0700
                                                Re: Operator Precedence/Boolean Logic Chris Angelico <rosuav@gmail.com> - 2016-07-17 14:05 +1000
                                                  Re: Operator Precedence/Boolean Logic Rustom Mody <rustompmody@gmail.com> - 2016-07-16 23:44 -0700
                                                    Re: Operator Precedence/Boolean Logic Rustom Mody <rustompmody@gmail.com> - 2016-07-16 23:59 -0700
                                                    Re: Operator Precedence/Boolean Logic Chris Angelico <rosuav@gmail.com> - 2016-07-17 17:33 +1000
                                                      Re: Operator Precedence/Boolean Logic Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-17 00:44 -0700
                                                        Re: Operator Precedence/Boolean Logic Steven D'Aprano <steve@pearwood.info> - 2016-07-17 20:04 +1000
                                                    Re: Operator Precedence/Boolean Logic Steven D'Aprano <steve@pearwood.info> - 2016-07-17 21:02 +1000
                                                      Re: Operator Precedence/Boolean Logic Rustom Mody <rustompmody@gmail.com> - 2016-07-17 08:00 -0700
                                                        Re: Operator Precedence/Boolean Logic Steven D'Aprano <steve@pearwood.info> - 2016-07-18 01:58 +1000
                                                          Re: Operator Precedence/Boolean Logic Steven D'Aprano <steve@pearwood.info> - 2016-07-18 02:01 +1000
                                            Re: Operator Precedence/Boolean Logic Chris Angelico <rosuav@gmail.com> - 2016-07-17 03:06 +1000
                                      Re: Operator Precedence/Boolean Logic Rustom Mody <rustompmody@gmail.com> - 2016-07-16 05:15 -0700
                                        Re: Operator Precedence/Boolean Logic Steven D'Aprano <steve@pearwood.info> - 2016-07-17 02:36 +1000
                          Re: Operator Precedence/Boolean Logic Grant Edwards <grant.b.edwards@gmail.com> - 2016-06-29 15:00 +0000
                            Re: Operator Precedence/Boolean Logic Jon Ribbens <jon+usenet@unequivocal.eu> - 2016-06-29 15:05 +0000
                            Re: Operator Precedence/Boolean Logic Steven D'Aprano <steve@pearwood.info> - 2016-06-30 09:44 +1000
                  Re: Operator Precedence/Boolean Logic Andreas Röhler <andreas.roehler@online.de> - 2016-06-23 11:51 +0200
          Re: Operator Precedence/Boolean Logic Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-06-23 17:20 +1000
          Re: Operator Precedence/Boolean Logic Random832 <random832@fastmail.com> - 2016-06-23 09:18 -0400
        Re: Operator Precedence/Boolean Logic Christian Gollwitzer <auriocus@gmx.de> - 2016-06-23 09:11 +0200
      Re: Operator Precedence/Boolean Logic Elizabeth Weiss <cake240@gmail.com> - 2016-06-22 21:22 -0700
    Fwd: Operator Precedence/Boolean Logic Jorge Gimeno <jlgimeno71@gmail.com> - 2016-06-21 20:56 -0700
    Re: Operator Precedence/Boolean Logic Random832 <random832@fastmail.com> - 2016-06-22 10:10 -0400
    Re: Operator Precedence/Boolean Logic Erik <python@lucidity.plus.com> - 2016-06-22 20:43 +0100

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#110374

On Thursday 23 June 2016 16:34, Andreas Röhler wrote:

> Indeed, why should the result of 4 - 4 have a different truth-value than
> 4 - 3 ?

Because 4-4 is zero, which is "nothing", while 4-3 is one, which is 
"something".

You might as well ask why False and True have different truth values. 
Ironically, in a manner of speaking you *did* ask that, since 4-3 == True and 
4-4 == False.


-- 
Steve

[toc] | [prev] | [next] | [standalone]

#110380

Op 23-06-16 om 09:05 schreef Steven D'Aprano:
> On Thursday 23 June 2016 16:34, Andreas Röhler wrote:
>
>> Indeed, why should the result of 4 - 4 have a different truth-value than
>> 4 - 3 ?
> Because 4-4 is zero, which is "nothing", while 4-3 is one, which is 
> "something".

No zero is not nothing. If zere is nothing and an empty list is nothing,
I would expect zero to be an empty list or that they could be used interchangebly.

For instance in a project of mine polling for information and
receiving an empty list is different from receiving None. An empty
list means there is currently no information available. None means
The information streams came to an end.

I rarely need tests where any truthy value will branch in one
direction and any falsy value in the other. So IMO it is more
hassle than it is worth.

-- 
Antoon.

[toc] | [prev] | [next] | [standalone]

#110384

On Thursday 23 June 2016 18:17, Antoon Pardon wrote:

> No zero is not nothing.

I think you have just disagreed with about four thousand years of 
mathematicians and accountants.

In fact, mathematicians were so hung up about zero being nothing, that it took 
about three thousand years before they accepted zero as a number (thanks to 
Indian mathematicians, via Arab mathematicians).

> If zere is nothing and an empty list is nothing,
> I would expect zero to be an empty list or that they could be used
> interchangebly.

You must have real trouble with statically typed languages then. Some of them 
won't even let you add 0.0 + 1 (since 0.0 is a float and 1 is an int).

> For instance in a project of mine polling for information and
> receiving an empty list is different from receiving None.

Okay. How is this relevant to the question of bools? If Python had "real bools" 
(in, say, the Pascal sense) you would still need to distinguish None from an 
empty list:

if info is None:
   print("done")
elif info:  # duck-typing version
            # "real bools" version uses "info != []" instead
   print("processing...")
else:
   print("nothing to process")


In fact, in this case chances are you probably don't even care to distinguish 
between empty and non-empty lists. What (I imagine) you probably care about is 
None versus any list:

if info is None:
   print("done")
else:
    for item in info:
        print("processing...")


> I rarely need tests where any truthy value will branch in one
> direction and any falsy value in the other.

That's reasonable. Few people do, except in the general case that they write 
some code that accepts any arbitrary truthy value. But more often, you expect 
that you are inspecting an object of some specific type, say, a sequence (list, 
tuple, deque, etc):

if seq:
    process()
else:
    handle_empty_case()


or a mapping (dict, UserDict, etc):

if mapping:
    process()
else:
    handle_empty_case()


or a Widget:

if widget:
    process()
else:
    handle_empty_case()


where you ask the object in question whether or not it should be considered 
empty ("nothing") or not ("something"), rather than having to call a type-
specific piece of code for each one:

if len(seq) == 0: ...

if mapping.isempty(): ...

if widget.isnullwidget(): ...



It's just duck-typing. Bools have certain behaviour in certain contexts, and 
*all* objects get the opportunity to quack like a bool in that context.



-- 
Steve

[toc] | [prev] | [next] | [standalone]

#110390

Op 23-06-16 om 10:48 schreef Steven D'Aprano:
> On Thursday 23 June 2016 18:17, Antoon Pardon wrote:
>
>> No zero is not nothing.
> I think you have just disagreed with about four thousand years of 
> mathematicians and accountants.

I don't care. In modern mathematics, zero is usaly defined as the
empty set. The empty set contains nothing, but it isn't nothing
itself. Otherwise the empty set would be the same as the set
containing the empty set, since they both would contain the same,
being nothing.

So modern mathematics seems to agree with me and that is enough
for me.

>> If zere is nothing and an empty list is nothing,
>> I would expect zero to be an empty list or that they could be used
>> interchangebly.
> You must have real trouble with statically typed languages then. Some of them 
> won't even let you add 0.0 + 1 (since 0.0 is a float and 1 is an int).

Your conclusion is a non sequitur.
 

>> For instance in a project of mine polling for information and
>> receiving an empty list is different from receiving None.
> Okay. How is this relevant to the question of bools? If Python had "real bools" 
> (in, say, the Pascal sense) you would still need to distinguish None from an 
> empty list:

It illustrates the distinction python makes into truthy and falsy, is often
enough inadequate.

A language with real bools would force you to write out the actual expression
you want and wouldn't tempt you to write something you think will work out
fine.

The zen of python states that explicit is better than implicit, but the
"boolean" semantics of python seem to encourage people to rely on a
lot of implicit things that are going on.

-- 
Antoon Pardon.

[toc] | [prev] | [next] | [standalone]

#110407

On Thu, Jun 23, 2016 at 7:23 PM, Antoon Pardon
<antoon.pardon@rece.vub.ac.be> wrote:
> I don't care. In modern mathematics, zero is usaly defined as the
> empty set. The empty set contains nothing, but it isn't nothing
> itself. Otherwise the empty set would be the same as the set
> containing the empty set, since they both would contain the same,
> being nothing.

Zero is *the cardinality of* the empty set. The set containing the
empty set has a cardinality of 1.

ChrisA

[toc] | [prev] | [next] | [standalone]

#110410

Op 23-06-16 om 13:45 schreef Chris Angelico:
> On Thu, Jun 23, 2016 at 7:23 PM, Antoon Pardon
> <antoon.pardon@rece.vub.ac.be> wrote:
>> I don't care. In modern mathematics, zero is usaly defined as the
>> empty set. The empty set contains nothing, but it isn't nothing
>> itself. Otherwise the empty set would be the same as the set
>> containing the empty set, since they both would contain the same,
>> being nothing.
> Zero is *the cardinality of* the empty set. The set containing the
> empty set has a cardinality of 1.

In modern set theory where the integers are defined as specific kind
of sets, zero *is* the empty set.

-- 
Antoon.

[toc] | [prev] | [next] | [standalone]

#110413

On 23.06.2016 14:08, Antoon Pardon wrote:
> Op 23-06-16 om 13:45 schreef Chris Angelico:
>> On Thu, Jun 23, 2016 at 7:23 PM, Antoon Pardon
>> <antoon.pardon@rece.vub.ac.be> wrote:
>>> I don't care. In modern mathematics, zero is usaly defined as the
>>> empty set. The empty set contains nothing, but it isn't nothing
>>> itself. Otherwise the empty set would be the same as the set
>>> containing the empty set, since they both would contain the same,
>>> being nothing.
>> Zero is *the cardinality of* the empty set. The set containing the
>> empty set has a cardinality of 1.
> In modern set theory where the integers are defined as specific kind
> of sets, zero *is* the empty set.
>

Modes are like waves. If one wave arrives being "modern", lets watch out 
for the next.

There not just one set-theory, math is neither revealed nor received on 
some mount - even if the notion of truth has some theological 
connotations ;)

[toc] | [prev] | [next] | [standalone]

#110381

On 23.06.2016 09:05, Steven D'Aprano wrote:
> On Thursday 23 June 2016 16:34, Andreas Röhler wrote:
>
>> Indeed, why should the result of 4 - 4 have a different truth-value than
>> 4 - 3 ?
> Because 4-4 is zero, which is "nothing",

Hmm,  water freezes at zero degree celsius, because there is no temperature?

>   while 4-3 is one, which is
> "something".
>
> You might as well ask why False and True have different truth values.
> Ironically, in a manner of speaking you *did* ask that, since 4-3 == True and
> 4-4 == False.
>
>

[toc] | [prev] | [next] | [standalone]

#110382

On 23.06.2016 10:17, Antoon Pardon wrote:
> Op 23-06-16 om 09:05 schreef Steven D'Aprano:
>> On Thursday 23 June 2016 16:34, Andreas Röhler wrote:
>>
>>> Indeed, why should the result of 4 - 4 have a different truth-value than
>>> 4 - 3 ?
>> Because 4-4 is zero, which is "nothing", while 4-3 is one, which is
>> "something".
> No zero is not nothing. If zere is nothing and an empty list is nothing,
> I would expect zero to be an empty list or that they could be used interchangebly.
>
>

There is a fundamental diff between zero and emptiness.

Zero is just a relation in the realm of integers. It tells being in the 
midst between positiv and negativ infinity.
Number one tells being one unit towards positiv infinity in relation to 
negativ infinity. And so on.

Whilst emptiness tells about non-existence.

[toc] | [prev] | [next] | [standalone]

#110389

On Thursday 23 June 2016 18:32, Andreas Röhler wrote:

> There is a fundamental diff between zero and emptiness.

In English, "emptiness" implies a container (real or figurative). The container 
is not "something or nothing", it is the *contents* being referred to.

"This shopping bag is empty" doesn't mean the shopping bag is nothing. It means 
that the set of items in the bad is the null set, i.e. there are ZERO items in 
the bag.

"My fridge is empty" doesn't mean that the fridge is nothing. It means that the 
set of items in the fridge is the null set, i.e. there are ZERO items in the 
fridge.

"That guy's head is empty" doesn't mean his head is nothing, it means that the 
set of thoughts in his head is the null set, i.e. he has ZERO thoughts. (This, 
of course, should be read figuratively, not literally.)


> Zero is just a relation in the realm of integers. It tells being in the
> midst between positiv and negativ infinity.

No, zero is not "a relation". It is an integer, and a very special one.

- zero is neither positive nor negative;
- zero is the additive identity: n+0 == n
- zero is multiplicative nullity;  n*0 == 0
- division by zero is undefined.

It is an artifact of the way we draw the number line (a *picture*) that zero is 
halfway between positive and negative:

<----------------------+------------------------>
  -4   -3   -2   -1    0    1    2    3    4

We could have draw it like this, with zero at the extreme left hand end:


  -3 /
 -2 /
-1 /
0 +
 1 \
  2 \
   3 \

although that would make graphing look a bit weird. 

(That's what we do with the extended Reals: we bend the number line around in a 
circle, with 0 at one pole and ±infinity at the other.)

But don't confuse the concrete representation of numbers on a line with the 
abstract numbers themselves.

In practical sense, there is a difference between having zero sheep and having 
one sheep, two sheep, three sheep, ... and of course nobody has even actually 
had negative one sheep.


> Number one tells being one unit towards positiv infinity in relation to
> negativ infinity. And so on.
> 
> Whilst emptiness tells about non-existence.

We can derive arithmetic from set theory. Zero is very special: it is defined 
as the empty set:

0: {}

The successor of zero (namely, one) is the set of all empty sets:

1: {{}}

Two is the set of zero and one:

2 = {{}, {{}}}

and so forth.



-- 
Steve

[toc] | [prev] | [next] | [standalone]

#110394

Steven D'Aprano <steve+comp.lang.python@pearwood.info>:

> On Thursday 23 June 2016 18:32, Andreas Röhler wrote:
>
>> There is a fundamental diff between zero and emptiness.
>
> In English, "emptiness" implies a container (real or figurative). The
> container is not "something or nothing", it is the *contents* being
> referred to.
>
> "This shopping bag is empty" doesn't mean the shopping bag is nothing.
> It means that the set of items in the bad is the null set, i.e. there
> are ZERO items in the bag.

I once read this puzzle in a book:

   There was a shipwreck in the middle of an ocean. The ship and the
   cargo were lost, but five sailors managed to swim to the beach of a
   nearby island. After quick scouting, the sailors realized they were
   on a tiny desert island with lots of coconut trees loaded with
   coconuts.

   The sailors set out to collect all coconuts they could find. After
   several hours, they had finished the job and made a sizeable pile of
   coconuts on the beach. They were exhausted and it was getting dark so
   they agreed to divide the pile evenly between each other on the
   following morning. They camped on the beach for the night.

   One of the sailors couldn't sleep. Would the others give him his
   share? What if they overpowered him and left him without coconuts? He
   sneaked to the pile of coconuts, split the big pile evenly into five
   smaller piles. One was left over, he threw it to a monkey that was
   watching nearby. He took his fifth, carried the coconuts to a secret
   location, and put the rest of the coconuts in a single pile so others
   wouldn't notice the loss. He went back to the camp and fell sound
   asleep.

   Another sailer woke up. What if he wouldn't get his share of the
   coconuts? He went to the big pile, divided it evenly into five
   smaller piles (one coconut was left over -- he threw it to the
   monkey), hid his share, put the big pile back together, and went to
   sleep.

   Before dawn, each of the sailors had gone through the same exercise.
   When they woke up, they went to the pile. Everyone noticed the pile
   had shrunk during the night but nobody mentioned it. They divided the
   pile evenly between the five. One coconut was left over and they
   threw it to the monkey.

   How many coconuts were there in the pile originally?


The book went on to find the answer(s), but gave also this interesting
side solution:

   The pile originally had -4 coconuts. The first sailor threw one to
   the monkey, leaving -5 coconuts in the pile. He took his share (-1
   coconut) out and put the remaining -4 coconuts back in the big pile.

   And so on.


Ridiculous? It was this line of thinking that led Paul Dirac to predict
the existence of antimatter.


Marko

[toc] | [prev] | [next] | [standalone]

#110399

On 23.06.2016 11:46, Marko Rauhamaa wrote:
>
> Ridiculous? It was this line of thinking that led Paul Dirac to predict
> the existence of antimatter.
>
>
> Marko

Yeah. Maybe we could construct examples already using antagonistic 
charges of electrons?

[toc] | [prev] | [next] | [standalone]

#110503

Marko Rauhamaa wrote:

>    The pile originally had -4 coconuts. The first sailor threw one to
>    the monkey, leaving -5 coconuts in the pile. He took his share (-1
>    coconut) out and put the remaining -4 coconuts back in the big pile.

Sounds a bit like Hawking radiation. A coconut-anticoconut
pair is created, and before they can recombine, the monkey
grabs the coconut, leaving the sailor with the anticoconut.

Unfortunately, it's pointless fot the sailor to eat the
anticocounut, as it would ony make him hungrier, and the
coconut is now inside the monkey's event horizon, never to
be seen again.

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#110767

Moved from thread "Assignment Versus Equality" where this is less relevant
============


On Wednesday, June 29, 2016 at 8:06:10 AM UTC+5:30, Steven D'Aprano wrote:
> On Tue, 28 Jun 2016 12:10 am, Rustom Mody wrote:
> 
> > Analogy: Python's bool as 1½-class because bool came into python a good
> > decade after python and breaking old code is a bigger issue than fixing
> > control constructs to be bool-strict
> 
> That analogy fails because Python bools being implemented as ints is not a
> bug to be fixed, but a useful feature.
> 
> There are downsides, of course, but there are also benefits. It comes down
> to a matter of personal preference whether you think that bools should be
> abstract True/False values or concrete 1/0 values. Neither decision is
> clearly wrong, it's a matter of what you value.
> 
> Whereas some decisions are just dumb:
> 
> https://www.jwz.org/blog/2010/10/every-day-i-learn-something-new-and-stupid/

When we were kids we used to have 'pillow-fights' -- such fun!

So if we are in a link-pillow-fight here is a link
https://mail.python.org/pipermail/python-ideas/2016-June/040780.html
in which python-dev Nick Coghlan answers the question:

> Q: ...supporting arithmetical operations (1+True==2) was a primary
> intention, in which case my question is "why?".
> 
> Nick: The inheritance from int meant the default behaviour was to support
> type-promoting integer arithmetic operations in addition to bitwise
> arithmetic.
> 
> That changes the question from "Why support that?" to "Why do the extra
> design, documentation and implementation work needed to prevent that?".
> 
> The fact that "1 + True == 2" is surprising hasn't proven to be enough to
> motivate anyone to define the precise subset of operations they want to
> prevent, and then make the case for those restrictions as Python's native
> behaviour.


Well enough of link-ing.

There are many aspects of bool's ½-assed status as a legitimate bool-type
of which 1+True==2 is a silly but not very significant/expensive consequence.

More significant...

Steven D'Aprano wrote:

> So we have falsey values:
>  
> - None
> - zeroes (0, 0.0, 0j, etc)
> - empty dict {}
> - empty sets and frozensets
> - empty strings '' and b'' (in Python 2: u'' and '')
> - empty lists, tuples and other sequences
>  
> and truthy values:
>  
> - object
> - non-zero numbers
> - non-empty dicts
> - non-empty sets and frozensets
> - non-empty strings
> - non-empty sequences
>  
> This is an improvement over other languages like Javascript, Ruby, etc where
> the division between truthy and falsey appears to be fairly arbitrary.

Likewise and more strongly

Chris wrote :
> If your RedBlackTree object were always *true*, I'd
> call it a missing feature ("please add a __bool__ that distinguishes
> empty trees from trees with content"), but always *false* would be a
> bug. A SortedDict implies by its name that it should be extremely
> dict-like, so that would be a strong argument for its truthiness to
> follow a dict's. Either way, the misbehaviour gets pointed back at the
> object in question.

And Marko wrote:
> I don't particularly like Python's falsey/truthy semantics,
> but I can live with it. The biggest problem I have with it is the
> absence of an emptiness predicate. I'd like to be able to write:

<elsewhere>

> The point is, Python has already declared that __bool__ is the
> canonical emptiness checker. You could even say that it's the
> principal purpose of the __bool__ method.

In short,
- Steven hints that empty/non-empty is some sort of *generic* property of data structures
- Chris strengthens that to include types outside of builtins -- Red-Black trees
- Marko (thankfully adding the I dont like) connects emptiness to the dunder
__bool__

So here's some questions for the bool-fans

Please show me how we would define __bool__ for

1. Graphs -- the kind mathematicians define with "Let G =(V,E) be a graph..."

2. Automata which in a way are special kinds of graphs

3. Regular Expressions which mathematically are related to automata
  And pragmatically are (more) present in python than the first two

It may (or may not) be helpful to pretend that python which already has
a regexp module/type also has explicit regexp syntax a la Perl.

[toc] | [prev] | [next] | [standalone]

#110771

On Wed, Jun 29, 2016 at 8:21 PM, Rustom Mody <rustompmody@gmail.com> wrote:
>
> Please show me how we would define __bool__ for
>
> 1. Graphs -- the kind mathematicians define with "Let G =(V,E) be a graph..."
>
> 2. Automata which in a way are special kinds of graphs
>
> 3. Regular Expressions which mathematically are related to automata
>   And pragmatically are (more) present in python than the first two
>
> It may (or may not) be helpful to pretend that python which already has
> a regexp module/type also has explicit regexp syntax a la Perl.

Probably the easiest way, for each of these objects, is to not define
__bool__ at all, or to define it thus:

    def __bool__(self):
        return True

If an object isn't a container, but is just a "thing", then it is by
definition true. The contrast isn't between [1] and [], but rather
between object() and None. It's perfectly reasonable for an object to
be always true - that's what the default object type does. You could
perhaps argue that a graph can be empty, but unless you're frequently
wanting to distinguish between empty graphs and non-empty graphs, I'd
stick with the default and make them always true. Note, for instance:

>>> bool(re.compile(""))
True

I think that's about as empty as a regex can be, and it's still true.
And regex match objects are always true, too - the match functions
will all return None if there's no match. Not all objects need to be
able to be falsey.

ChrisA

[toc] | [prev] | [next] | [standalone]

#110775

On Wed, 29 Jun 2016 08:21 pm, Rustom Mody wrote:

> So if we are in a link-pillow-fight here is a link
> https://mail.python.org/pipermail/python-ideas/2016-June/040780.html
> in which python-dev Nick Coghlan answers the question:
> 
>> Q: ...supporting arithmetical operations (1+True==2) was a primary
>> intention, in which case my question is "why?".
>> 
>> Nick: The inheritance from int meant the default behaviour was to support
>> type-promoting integer arithmetic operations in addition to bitwise
>> arithmetic.
>> 
>> That changes the question from "Why support that?" to "Why do the extra
>> design, documentation and implementation work needed to prevent that?".
>> 
>> The fact that "1 + True == 2" is surprising hasn't proven to be enough to
>> motivate anyone to define the precise subset of operations they want to
>> prevent, and then make the case for those restrictions as Python's native
>> behaviour.


Nick is a very senior core developer, and we would be foolish to ignore his
opinion, but that doesn't make his comments gospel.

To Nick, having 1+True return 2 is an accident of implementation, where it
is too much work to prevent it for the minimal gain it would give. And
historically, that was Guido's attitude back when Python gained a bool
type.

(Initially Python gained to pseudo-constants, True and False, set equal to 1
and 0; then in the following release it gained a built-in type bool that
subclassed int, with exactly two instances, True and False.)

But it is my argument that with (roughly) ten years of experience with us,
we can say that 1+True == 2 is not just an unfortunate accident of
implementation that we are forced to live with because nobody wants to do
the work to correct it. Rather, it is a useful and desirable feature. If I
were designing a new language from scratch, I would probably follow
Python's lead and use an int subclass for bools.

As I said before, this isn't to dispute or deny the fact that bools-as-ints
have unfortunate consequences. But they have useful consequences too, and
in my opinion they outweigh the bad ones.

If you disagree, okay, you disagree. I like broccoli and hate streaky bacon,
others feel the opposite way. I'm lucky that Python, due to historical
accident, ended up working the way I prefer. When you design your own
language, you can make it work the way you prefer.


[...]
> More significant...
> 
> Steven D'Aprano wrote:
> 
>> So we have falsey values:

Note that the question of truthy/falsey duck-typed bools is independent of
whether bools are abstract flags or concrete ints. A language could:

- have a dedicated, abstract bool type, like Pascal does;

- completely do without a dedicated bool type, and just have truthy/falsey
values, like Python 1.5 did;

- allow all values to be treated as truthy/falsey values, but have a
concrete (int-subclass) bool type as the canonical true/false, like Python
2 & 3 does;

- allow all values to be treated as truthy/falsey values, but have an
abstract bool type as the canonical true/false, like Javascript does.

So the question of truthy/falsey values is orthogonal to the question of
whether bool should inherit from int.


> In short,
> - Steven hints that empty/non-empty is some sort of *generic* property of
> data structures - Chris strengthens that to include types outside of
> builtins -- Red-Black trees - Marko (thankfully adding the I dont like)
> connects emptiness to the dunder __bool__

It's not just a hint. Python has a convention that empty collections should
be treated as falsey; likewise empty sequences; likewise "empty" numbers.
And non-empty ones should be treated as truthy. This is built into the way
the interpreter decides whether something is truthy or falsey.

Given:

    if spam: ...
     else: ...


Python decides which branch to take as follows:

- if spam has a __len__ method, and spam.__len__() returns 0, then spam is
falsey and the `else` branch is taken;

- if spam.__len__() returns a non-zero number, then spam is truthy and the
`if` branch is taken;

- otherwise, if spam has a __nonzero__ method (__bool__ in Python 3), if it
returns a falsey value, then spam is falsey;

- but if it returns a truthy value, then spam is truthy;

- and if spam has neither a __len__ nor a __nonzero__ / __bool__ method,
then by default it is truthy.


 
> So here's some questions for the bool-fans
> 
> Please show me how we would define __bool__ for
> 
> 1. Graphs -- the kind mathematicians define with "Let G =(V,E) be a
> graph..."

I would make the empty graph (zero nodes) falsey, and non-empty graphs (one
or more nodes) truthy.


> 2. Automata which in a way are special kinds of graphs

As above.


> 3. Regular Expressions which mathematically are related to automata
>   And pragmatically are (more) present in python than the first two

Can you even have an empty regular expression? What does it match? Possibly
nothing at all.

Ideally, I would have the empty regular expression be falsey, and all others
truthy, but I wouldn't be too upset if all regexes were True.




-- 
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

[toc] | [prev] | [next] | [standalone]

#110777

On Wednesday, June 29, 2016 at 6:38:16 PM UTC+5:30, Steven D'Aprano wrote:
> On Wed, 29 Jun 2016 08:21 pm, Rustom Mody wrote:
> > 3. Regular Expressions which mathematically are related to automata
> >   And pragmatically are (more) present in python than the first two
> 
> Can you even have an empty regular expression? What does it match? Possibly
> nothing at all.
> 
> Ideally, I would have the empty regular expression be falsey, and all others
> truthy, but I wouldn't be too upset if all regexes were True.

Salutations!

Chris fell into the trap -- if I take his "" as
> I think that's about as empty as a regex can be, 

You have not fallen in... Admirable!
What you need is a negative lookahead empty re  (?!)


>>> re.findall("", "")
['']
>>> re.findall("(?!)", "")
[]
>>> re.findall("(?!)", "a")
[]
>>> re.findall("", "a")
['', '']
>>> 

The other answers -- graphs and automata -- are questionable and/or wrong

You may wish to think about them again?

[toc] | [prev] | [next] | [standalone]

#110788

On Wed, 29 Jun 2016 11:30 pm, Rustom Mody wrote:

> The other answers -- graphs and automata -- are questionable and/or wrong
> 
> You may wish to think about them again?

You may wish to justify your assertion.




-- 
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

[toc] | [prev] | [next] | [standalone]

#110852

On Thursday, June 30, 2016 at 5:10:41 AM UTC+5:30, Steven D'Aprano wrote:
> On Wed, 29 Jun 2016 11:30 pm, Rustom Mody wrote:
> 
> > The other answers -- graphs and automata -- are questionable and/or wrong
> > 
> > You may wish to think about them again?
> 
> You may wish to justify your assertion.

> Rusi wrote
> > Please show me how we would define __bool__ for
> >
> > 1. Graphs -- the kind mathematicians define with "Let G =(V,E) be a
> > graph..."

> I would make the empty graph (zero nodes) falsey, and non-empty graphs (one
> or more nodes) truthy.


> 2. Automata which in a way are special kinds of graphs

As above. 

From https://en.wikipedia.org/wiki/Finite-state_machine#Mathematical_model

A deterministic finite state machine (acceptor) is a quintuple
(Σ, S, δ, s₀, F), where:

    Σ  is the input alphabet (a finite, non-empty set of symbols).
    S  is a finite, non-empty set of states.
    δ  is the state-transition function: δ : S × Σ → S 
    s₀  is an initial state, an element of S.
    F  is the set of final states, a (possibly empty) subset of S.


Put in more succinct form:

If we take Σ (alphabet) and S (state-set) as given (ie independent) types
we can specify the dependence of s₀ δ and F as the following type_signature:

dfa(Σ, S) = s₀ : S
            δ : S × Σ → S
	    F : ℘ S

Since s₀ : S is part of the dfa spec, S cant be empty

Can Σ (alphabet) be empty??
I'm not clear on that one...

[toc] | [prev] | [next] | [standalone]

#110854

On Fri, 1 Jul 2016 02:01 am, Rustom Mody wrote:

> On Thursday, June 30, 2016 at 5:10:41 AM UTC+5:30, Steven D'Aprano wrote:
>> On Wed, 29 Jun 2016 11:30 pm, Rustom Mody wrote:
>> 
>> > The other answers -- graphs and automata -- are questionable and/or
>> > wrong
>> > 
>> > You may wish to think about them again?
>> 
>> You may wish to justify your assertion.

[snip]

Okay, if you think that automata cannot be empty, I'll accept that. In that
case, then I'll change my answer and say that __bool__ for automata should
simply return True. All automata should be truthy.




-- 
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

[toc] | [prev] | [next] | [standalone]

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

Back to top | Article view | comp.lang.python

csiph-web