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

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

Re: while loop - multiple condition

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: while loop - multiple condition Chris Angelico <rosuav@gmail.com> - 2014-10-13 05:03 +1100
    Re: while loop - multiple condition Marko Rauhamaa <marko@pacujo.net> - 2014-10-12 22:16 +0300
      Re: while loop - multiple condition Chris Angelico <rosuav@gmail.com> - 2014-10-13 06:22 +1100
      Re: while loop - multiple condition Tim Chase <python.list@tim.thechases.com> - 2014-10-12 15:42 -0500
        Re: while loop - multiple condition Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-10-13 09:56 +1100
          Re: while loop - multiple condition Rob Gaddi <rgaddi@technologyhighland.invalid> - 2014-10-13 09:12 -0700
            Re: while loop - multiple condition Rustom Mody <rustompmody@gmail.com> - 2014-10-13 09:26 -0700
              Re: while loop - multiple condition Rob Gaddi <rgaddi@technologyhighland.invalid> - 2014-10-13 09:43 -0700
                Re: while loop - multiple condition Rustom Mody <rustompmody@gmail.com> - 2014-10-13 10:12 -0700
                  Re: while loop - multiple condition Michael Torrie <torriem@gmail.com> - 2014-10-13 16:08 -0600
                    Re: while loop - multiple condition wxjmfauth@gmail.com - 2014-10-13 23:34 -0700
        Re: while loop - multiple condition giacomo boffi <pecore@pascolo.net> - 2014-10-15 01:04 +0200
          Re: while loop - multiple condition Chris Angelico <rosuav@gmail.com> - 2014-10-15 10:16 +1100

#79012 — Re: while loop - multiple condition

On Mon, Oct 13, 2014 at 4:59 AM, Shiva
<shivaji_tn@yahoo.com.dmarc.invalid> wrote:
> Bit confusing to use in While loop - Should have used the 'and' condition
> instead of OR- then it works fine.
> for OR both condition need to be false to produce a false output and break
> the loop.

Correct, what you're looking for here is indeed an 'and' (also called
a conjunction, as opposed to the disjunction of 'or'). Both operators
are important; and you need to understand what they do so you know
when to use each.

ChrisA

[toc] | [next] | [standalone]

#79017

Chris Angelico <rosuav@gmail.com>:

> On Mon, Oct 13, 2014 at 4:59 AM, Shiva
> <shivaji_tn@yahoo.com.dmarc.invalid> wrote:
>> Bit confusing to use in While loop - Should have used the 'and' condition
>> instead of OR- then it works fine.
>> for OR both condition need to be false to produce a false output and break
>> the loop.
>
> Correct, what you're looking for here is indeed an 'and' (also called
> a conjunction, as opposed to the disjunction of 'or'). Both operators
> are important; and you need to understand what they do so you know
> when to use each.

The corrected version

    while ans.lower() != 'yes' and ans.lower()[0] != 'y':
         ans = input('Do you like python?')

is equivalent with

    while ans.lower()[0] != 'y':
         ans = input('Do you like python?')


Marko

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

#79018

On Mon, Oct 13, 2014 at 6:16 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> The corrected version
>
>     while ans.lower() != 'yes' and ans.lower()[0] != 'y':
>          ans = input('Do you like python?')
>
> is equivalent with
>
>     while ans.lower()[0] != 'y':

It's true that the first part is redundant, but trimming that out
wouldn't have taught the OP about boolean logic :)

ChrisA

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

#79024

On 2014-10-12 22:16, Marko Rauhamaa wrote:
> is equivalent with
> 
>     while ans.lower()[0] != 'y':
>          ans = input('Do you like python?')

And still better improved with

  while ans[:1].lower() != 'y':
    ans = input('Do you like python?')

in the event that len(ans)==0 (a situation which will crash the
various current examples).

It also only expends the effort to lowercase 0-or-1 characters,
rather than lowercasing an entire string just to throw away
everything except the first character.

-tkc

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

#79025

Tim Chase wrote:

> On 2014-10-12 22:16, Marko Rauhamaa wrote:
>> is equivalent with
>> 
>>     while ans.lower()[0] != 'y':
>>          ans = input('Do you like python?')
> 
> And still better improved with
> 
>   while ans[:1].lower() != 'y':
>     ans = input('Do you like python?')


The intention is to loop forever until the victim breaks down and accepts
that they like Python, by entering "yes" or "y". I'm pretty sure that
entering "yellow" or "you've got to be kidding" should not break the loop.

When you have multiple clauses in the condition, it's easier to reason about
them if you write the clauses as positive statements rather than negative
statements, that is, "something is true" rather than "something is not
true", and then use `not` to reverse it if you want to loop *until* the
overall condition is true.

When checking for equality against multiple values, instead of:

    x == a or x == b or x == c

it is usually easier to use `in`:

    x in (a, b, c)


So we have:

# loop so long as the victim answers "yes" or "y"
while ans.lower() in ('yes', 'y'):
    ans = input('Do you like python? Well, do you?')

# loop until the victim answers "yes" or "y"
while not (ans.lower() in ('yes', 'y')):
    ans = input('Do you like python? Well, do you?')


both of which work fine if the user stays mum by entering the empty string.

You can also write:

while ans.lower() not in ('yes', 'y'):
    ans = input('Do you like python? Well, do you?')


if you prefer. In my opinion, that's the most readable version of all.

One last note: if you are using Python 3.3 or better, you can support
international text better by using the casefold() method rather than
lower(). In this case, it won't make a difference, but the technically
correct method for doing case-insensitive comparisons is to casefold both
strings rather than lower- or upper-case them.


-- 
Steven

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

#79052

On Mon, 13 Oct 2014 09:56:02 +1100
Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
> 
> When you have multiple clauses in the condition, it's easier to reason about
> them if you write the clauses as positive statements rather than negative
> statements, that is, "something is true" rather than "something is not
> true", and then use `not` to reverse it if you want to loop *until* the
> overall condition is true.
> 

I was just explaining this concept to a young pup the other day.  De
Morgan's lets you say that (not (p and q)) == ((not p) or (not q)), but
the positive logic flavor is substantially less error-prone.  People
are fundamentally not as good at thinking about inverted logic.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

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

#79053

On Monday, October 13, 2014 9:43:03 PM UTC+5:30, Rob Gaddi wrote:
> On Mon, 13 Oct 2014 09:56:02 +1100
> Steven D'Aprano  wrote:
> > When you have multiple clauses in the condition, it's easier to reason about
> > them if you write the clauses as positive statements rather than negative
> > statements, that is, "something is true" rather than "something is not
> > true", and then use `not` to reverse it if you want to loop *until* the
> > overall condition is true.

> I was just explaining this concept to a young pup the other day.  De
> Morgan's lets you say that (not (p and q)) == ((not p) or (not q)), but
> the positive logic flavor is substantially less error-prone.  People
> are fundamentally not as good at thinking about inverted logic.

Curious: Which of

- (not (p and q))
- ((not p) or (not q))

is more positive (less negative)??

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

#79054

On Mon, 13 Oct 2014 09:26:57 -0700 (PDT)
Rustom Mody <rustompmody@gmail.com> wrote:

> On Monday, October 13, 2014 9:43:03 PM UTC+5:30, Rob Gaddi wrote:
> > On Mon, 13 Oct 2014 09:56:02 +1100
> > Steven D'Aprano  wrote:
> > > When you have multiple clauses in the condition, it's easier to reason about
> > > them if you write the clauses as positive statements rather than negative
> > > statements, that is, "something is true" rather than "something is not
> > > true", and then use `not` to reverse it if you want to loop *until* the
> > > overall condition is true.
> 
> > I was just explaining this concept to a young pup the other day.  De
> > Morgan's lets you say that (not (p and q)) == ((not p) or (not q)), but
> > the positive logic flavor is substantially less error-prone.  People
> > are fundamentally not as good at thinking about inverted logic.
> 
> Curious: Which of
> 
> - (not (p and q))
> - ((not p) or (not q))
> 
> is more positive (less negative)??

The first is asking you to compare positive conditions (p and q) and
negate the entire thing (NAND).  The second asks you to think about
the combination of two different "not true" pieces of logic
(OR of two inverted inputs).  The first is pretty straightforward, and
I usually see people get it right.  The second gets screwed up as often
as not.

And of course, any combination of ands and ors should be broken into
multiple statements with a descriptive variable name in the middle or
all hope is lost.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

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

#79055

On Monday, October 13, 2014 10:13:20 PM UTC+5:30, Rob Gaddi wrote:
> On Mon, 13 Oct 2014 09:26:57 -0700 (PDT)
> Rustom Mody  wrote:

> > On Monday, October 13, 2014 9:43:03 PM UTC+5:30, Rob Gaddi wrote:
> > > On Mon, 13 Oct 2014 09:56:02 +1100
> > > Steven D'Aprano  wrote:
> > > > When you have multiple clauses in the condition, it's easier to reason about
> > > > them if you write the clauses as positive statements rather than negative
> > > > statements, that is, "something is true" rather than "something is not
> > > > true", and then use `not` to reverse it if you want to loop *until* the
> > > > overall condition is true.
> > > I was just explaining this concept to a young pup the other day.  De
> > > Morgan's lets you say that (not (p and q)) == ((not p) or (not q)), but
> > > the positive logic flavor is substantially less error-prone.  People
> > > are fundamentally not as good at thinking about inverted logic.
> > Curious: Which of
> > - (not (p and q))
> > - ((not p) or (not q))
> > is more positive (less negative)??

> The first is asking you to compare positive conditions (p and q) and
> negate the entire thing (NAND).  The second asks you to think about
> the combination of two different "not true" pieces of logic
> (OR of two inverted inputs).  The first is pretty straightforward, and
> I usually see people get it right.  The second gets screwed up as often
> as not.

> And of course, any combination of ands and ors should be broken into
> multiple statements with a descriptive variable name in the middle or
> all hope is lost.

Yeah I guess 2 nots is one more than one!

However (to my eyes)
while i < N  and  a[i] != X:

looks less negative than

while not (i==N or a[i] == X):

[Of course i < N is not identical to i != N ]

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

#79071

On 10/13/2014 11:12 AM, Rustom Mody wrote:
> On Monday, October 13, 2014 10:13:20 PM UTC+5:30, Rob Gaddi wrote:
>> On Mon, 13 Oct 2014 09:26:57 -0700 (PDT)
>> Rustom Mody  wrote:
> 
>>> On Monday, October 13, 2014 9:43:03 PM UTC+5:30, Rob Gaddi wrote:
>>>> On Mon, 13 Oct 2014 09:56:02 +1100
>>>> Steven D'Aprano  wrote:
>>>>> When you have multiple clauses in the condition, it's easier to reason about
>>>>> them if you write the clauses as positive statements rather than negative
>>>>> statements, that is, "something is true" rather than "something is not
>>>>> true", and then use `not` to reverse it if you want to loop *until* the
>>>>> overall condition is true.
>>>> I was just explaining this concept to a young pup the other day.  De
>>>> Morgan's lets you say that (not (p and q)) == ((not p) or (not q)), but
>>>> the positive logic flavor is substantially less error-prone.  People
>>>> are fundamentally not as good at thinking about inverted logic.
>>> Curious: Which of
>>> - (not (p and q))
>>> - ((not p) or (not q))
>>> is more positive (less negative)??
> 
>> The first is asking you to compare positive conditions (p and q) and
>> negate the entire thing (NAND).  The second asks you to think about
>> the combination of two different "not true" pieces of logic
>> (OR of two inverted inputs).  The first is pretty straightforward, and
>> I usually see people get it right.  The second gets screwed up as often
>> as not.
> 
>> And of course, any combination of ands and ors should be broken into
>> multiple statements with a descriptive variable name in the middle or
>> all hope is lost.
> 
> Yeah I guess 2 nots is one more than one!
> 
> However (to my eyes)
> while i < N  and  a[i] != X:
> 
> looks less negative than
> 
> while not (i==N or a[i] == X):
> 
> [Of course i < N is not identical to i != N ]

Right it should have been not (i >= N or a[i] == X) to be equivalent.

In assembler it's often best to reverse the condition and then use the
opposite jump mnemonic. IE, if the test is to see if a number not zero,
use the jump if zero command instead.  Often it reduces the number of
jumps required and eliminates the need to jump over the body of the "if"
block.

if a != 0 then jump to bigger
jump to end
bigger:
blah
blah
end:

vs

if a == 0 then jump to end
blah
blah
end:

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

#79079

Le mardi 14 octobre 2014 00:09:08 UTC+2, Michael Torrie a écrit :
> On 10/13/2014 11:12 AM, Rustom Mody wrote:
> 
> > On Monday, October 13, 2014 10:13:20 PM UTC+5:30, Rob Gaddi wrote:
> 
> >> On Mon, 13 Oct 2014 09:26:57 -0700 (PDT)
> 
> >> Rustom Mody  wrote:
> 
> > 
> 
> >>> On Monday, October 13, 2014 9:43:03 PM UTC+5:30, Rob Gaddi wrote:
> 
> >>>> On Mon, 13 Oct 2014 09:56:02 +1100
> 
> >>>> Steven D'Aprano  wrote:
> 
> >>>>> When you have multiple clauses in the condition, it's easier to reason about
> 
> >>>>> them if you write the clauses as positive statements rather than negative
> 
> >>>>> statements, that is, "something is true" rather than "something is not
> 
> >>>>> true", and then use `not` to reverse it if you want to loop *until* the
> 
> >>>>> overall condition is true.
> 
> >>>> I was just explaining this concept to a young pup the other day.  De
> 
> >>>> Morgan's lets you say that (not (p and q)) == ((not p) or (not q)), but
> 
> >>>> the positive logic flavor is substantially less error-prone.  People
> 
> >>>> are fundamentally not as good at thinking about inverted logic.
> 
> >>> Curious: Which of
> 
> >>> - (not (p and q))
> 
> >>> - ((not p) or (not q))
> 
> >>> is more positive (less negative)??
> 
> > 
> 
> >> The first is asking you to compare positive conditions (p and q) and
> 
> >> negate the entire thing (NAND).  The second asks you to think about
> 
> >> the combination of two different "not true" pieces of logic
> 
> >> (OR of two inverted inputs).  The first is pretty straightforward, and
> 
> >> I usually see people get it right.  The second gets screwed up as often
> 
> >> as not.
> 
> > 
> 
> >> And of course, any combination of ands and ors should be broken into
> 
> >> multiple statements with a descriptive variable name in the middle or
> 
> >> all hope is lost.
> 
> > 
> 
> > Yeah I guess 2 nots is one more than one!
> 
> > 
> 
> > However (to my eyes)
> 
> > while i < N  and  a[i] != X:
> 
> > 
> 
> > looks less negative than
> 
> > 
> 
> > while not (i==N or a[i] == X):
> 
> > 
> 
> > [Of course i < N is not identical to i != N ]
> 
> 
> 
> Right it should have been not (i >= N or a[i] == X) to be equivalent.
> 
> 
> 
> In assembler it's often best to reverse the condition and then use the
> 
> opposite jump mnemonic. IE, if the test is to see if a number not zero,
> 
> use the jump if zero command instead.  Often it reduces the number of
> 
> jumps required and eliminates the need to jump over the body of the "if"
> 
> block.
> 
> 
> 
> if a != 0 then jump to bigger
> 
> jump to end
> 
> bigger:
> 
> blah
> 
> blah
> 
> end:
> 
> 
> 
> vs
> 
> 
> 
> if a == 0 then jump to end
> 
> blah
> 
> blah
> 
> end:

On the side of logic.
Nothing can beat this mathematical absurdity (in the
logical sense of the term) called Flexible String
Representation.

Simply unbelievable.

jmf

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

#79122

Tim Chase <python.list@tim.thechases.com> writes:

> On 2014-10-12 22:16, Marko Rauhamaa wrote:
>> is equivalent with
>> 
>>     while ans.lower()[0] != 'y':
>>          ans = input('Do you like python?')
>
> And still better improved with
>
>   while ans[:1].lower() != 'y':
>     ans = input('Do you like python?')

 yok is Turkish for an EMPHATIC NO
(or, at least, that's what I was led to think many years ago)

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

#79123

On Wed, Oct 15, 2014 at 10:04 AM, giacomo boffi <pecore@pascolo.net> wrote:
> Tim Chase <python.list@tim.thechases.com> writes:
>
>> On 2014-10-12 22:16, Marko Rauhamaa wrote:
>>> is equivalent with
>>>
>>>     while ans.lower()[0] != 'y':
>>>          ans = input('Do you like python?')
>>
>> And still better improved with
>>
>>   while ans[:1].lower() != 'y':
>>     ans = input('Do you like python?')
>
>  yok is Turkish for an EMPHATIC NO
> (or, at least, that's what I was led to think many years ago)

Corrupted core, are you ready to start the procedure?
What do you think?
Interpreting vague answer as: Yes!

If your program misinterprets a non-English response to an English
question, that's not critical. It just means you haven't implemented
full i18n. :)

ChrisA

[toc] | [prev] | [standalone]

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

csiph-web