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

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

Re: Check if a given value is out of certain range

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: Check if a given value is out of certain range Rob Gaddi <rgaddi@technologyhighland.invalid> - 2015-09-29 16:48 +0000
    Re: Check if a given value is out of certain range Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-29 21:32 +0100
      Re: Check if a given value is out of certain range sohcahtoa82@gmail.com - 2015-09-30 11:31 -0700
        Re: Check if a given value is out of certain range Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-30 23:31 +0100
          Re: Check if a given value is out of certain range Steven D'Aprano <steve@pearwood.info> - 2015-10-02 04:18 +1000
            Re: Check if a given value is out of certain range John Gordon <gordon@panix.com> - 2015-10-01 18:20 +0000
              Re: Check if a given value is out of certain range Steven D'Aprano <steve@pearwood.info> - 2015-10-02 05:19 +1000
                Re: Check if a given value is out of certain range John Gordon <gordon@panix.com> - 2015-10-01 19:41 +0000
                  Re: Check if a given value is out of certain range Marko Rauhamaa <marko@pacujo.net> - 2015-10-01 22:59 +0300
                    Re: Check if a given value is out of certain range Emile van Sebille <emile@fenx.com> - 2015-10-01 13:15 -0700
                    Re: Check if a given value is out of certain range John Gordon <gordon@panix.com> - 2015-10-01 21:45 +0000
                      Re: Check if a given value is out of certain range Ian Kelly <ian.g.kelly@gmail.com> - 2015-10-01 16:03 -0600
                      Re: Check if a given value is out of certain range Chris Kaynor <ckaynor@zindagigames.com> - 2015-10-01 15:48 -0700
                      Re: Check if a given value is out of certain range Ian Kelly <ian.g.kelly@gmail.com> - 2015-10-01 16:01 -0600
                      Re: Check if a given value is out of certain range Steven D'Aprano <steve@pearwood.info> - 2015-10-03 20:29 +1000
                        Re: Check if a given value is out of certain range Bartc <bc@freeuk.com> - 2015-10-03 11:48 +0100
                        Re: Check if a given value is out of certain range Laura Creighton <lac@openend.se> - 2015-10-03 14:12 +0200
                          Re: Check if a given value is out of certain range Steven D'Aprano <steve@pearwood.info> - 2015-10-03 23:51 +1000
                            Re: Check if a given value is out of certain range wxjmfauth@gmail.com - 2015-10-03 07:19 -0700
                          Re: Check if a given value is out of certain range Steven D'Aprano <steve@pearwood.info> - 2015-10-05 00:47 +1100
                            Re: Check if a given value is out of certain range Rustom Mody <rustompmody@gmail.com> - 2015-10-04 19:28 -0700
                              Re: Check if a given value is out of certain range Rustom Mody <rustompmody@gmail.com> - 2015-10-04 19:32 -0700
                      Re: Check if a given value is out of certain range Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-10-03 11:49 -0400
            Re: Check if a given value is out of certain range Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-10-02 00:34 +0100
        Re: Check if a given value is out of certain range Michiel Overtoom <motoom@xs4all.nl> - 2015-10-05 10:18 +0200
          Re: Check if a given value is out of certain range Jussi Piitulainen <harvesting@makes.email.invalid> - 2015-10-05 13:08 +0300
            Re: Check if a given value is out of certain range Marko Rauhamaa <marko@pacujo.net> - 2015-10-05 14:42 +0300
              Re: Check if a given value is out of certain range Chris Angelico <rosuav@gmail.com> - 2015-10-06 00:10 +1100
                Re: Check if a given value is out of certain range Marko Rauhamaa <marko@pacujo.net> - 2015-10-05 16:25 +0300
        Re: Check if a given value is out of certain range Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-10-05 10:19 +0100
    Re: Check if a given value is out of certain range Random832 <random832@fastmail.com> - 2015-09-29 17:04 -0400
      Re: Check if a given value is out of certain range Luca Menegotto <otlucaDELETE@DELETEyahoo.it> - 2015-09-30 07:57 +0200
    Re: Check if a given value is out of certain range Emile van Sebille <emile@fenx.com> - 2015-09-29 14:07 -0700
    Re: Check if a given value is out of certain range Ian Kelly <ian.g.kelly@gmail.com> - 2015-09-29 15:07 -0600
      Re: Check if a given value is out of certain range Steven D'Aprano <steve@pearwood.info> - 2015-09-30 11:55 +1000
        Re: Check if a given value is out of certain range Random832 <random832@fastmail.com> - 2015-09-29 23:08 -0400
          Re: Check if a given value is out of certain range Steven D'Aprano <steve@pearwood.info> - 2015-09-30 13:14 +1000
            Re: Check if a given value is out of certain range Ian Kelly <ian.g.kelly@gmail.com> - 2015-09-29 23:54 -0600
    Re: Check if a given value is out of certain range Tim Chase <python.list@tim.thechases.com> - 2015-09-29 18:44 -0500
      Re: Check if a given value is out of certain range alister <alister.nospam.ware@ntlworld.com> - 2015-09-30 09:41 +0000
        Re: Check if a given value is out of certain range John Gordon <gordon@panix.com> - 2015-09-30 15:42 +0000
        Re: Check if a given value is out of certain range Grant Edwards <invalid@invalid.invalid> - 2015-09-30 15:56 +0000
          Re: Check if a given value is out of certain range Marko Rauhamaa <marko@pacujo.net> - 2015-09-30 21:06 +0300
            Re: Check if a given value is out of certain range alister <alister.nospam.ware@ntlworld.com> - 2015-09-30 20:19 +0000
              Re: Check if a given value is out of certain range Ian Kelly <ian.g.kelly@gmail.com> - 2015-09-30 14:46 -0600
                Re: Check if a given value is out of certain range alister <alister.nospam.ware@ntlworld.com> - 2015-10-01 08:33 +0000
                  Re: Check if a given value is out of certain range Chris Angelico <rosuav@gmail.com> - 2015-10-01 18:37 +1000
                    Re: Check if a given value is out of certain range alister <alister.nospam.ware@ntlworld.com> - 2015-10-01 08:48 +0000
                  Re: Check if a given value is out of certain range Ian Kelly <ian.g.kelly@gmail.com> - 2015-10-01 08:14 -0600
                Re: Check if a given value is out of certain range Steven D'Aprano <steve@pearwood.info> - 2015-10-02 04:59 +1000
              Re: Check if a given value is out of certain range Laura Creighton <lac@openend.se> - 2015-10-01 09:40 +0200
              Re: Check if a given value is out of certain range Laura Creighton <lac@openend.se> - 2015-10-01 09:58 +0200

Page 1 of 3  [1] 2 3  Next page →

#97213 — Re: Check if a given value is out of certain range

On Tue, 29 Sep 2015 10:16:04 +0530, Laxmikant Chitare wrote:

> Hi,
> 
> I know there is an elegant way to check if a given value is within
> certain range.
> Example - To check if x is between zero and ten, I can do 0 < x 10.
> 
> Is there any similar elegant way to check if a value is out of certain
> range?
> Example - To check if x is either less than zero or greater than ten?
> Right now I am using x < 0 or x > 10.
> 
> Regards,
> Laxmikant

not (0 <= x <= 10)



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

[toc] | [next] | [standalone]

#97216

On 29/09/2015 17:48, Rob Gaddi wrote:
> On Tue, 29 Sep 2015 10:16:04 +0530, Laxmikant Chitare wrote:
>
>> Hi,
>>
>> I know there is an elegant way to check if a given value is within
>> certain range.
>> Example - To check if x is between zero and ten, I can do 0 < x 10.
>>
>> Is there any similar elegant way to check if a value is out of certain
>> range?
>> Example - To check if x is either less than zero or greater than ten?
>> Right now I am using x < 0 or x > 10.
>>
>> Regards,
>> Laxmikant
>
> not (0 <= x <= 10)
>

Yuck.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

#97251

On Tuesday, September 29, 2015 at 1:33:23 PM UTC-7, Mark Lawrence wrote:
> On 29/09/2015 17:48, Rob Gaddi wrote:
> > On Tue, 29 Sep 2015 10:16:04 +0530, Laxmikant Chitare wrote:
> >
> >> Hi,
> >>
> >> I know there is an elegant way to check if a given value is within
> >> certain range.
> >> Example - To check if x is between zero and ten, I can do 0 < x 10.
> >>
> >> Is there any similar elegant way to check if a value is out of certain
> >> range?
> >> Example - To check if x is either less than zero or greater than ten?
> >> Right now I am using x < 0 or x > 10.
> >>
> >> Regards,
> >> Laxmikant
> >
> > not (0 <= x <= 10)
> >
> 
> Yuck.
> 
> -- 
> My fellow Pythonistas, ask not what our language can do for you, ask
> what you can do for our language.
> 
> Mark Lawrence

What is so "yuck" about that?  What would you do instead?  It seems like the best solution to me.  Easy to read, fast to execute.

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

#97260

On 30/09/2015 19:31, sohcahtoa82@gmail.com wrote:
> On Tuesday, September 29, 2015 at 1:33:23 PM UTC-7, Mark Lawrence wrote:
>> On 29/09/2015 17:48, Rob Gaddi wrote:
>>> On Tue, 29 Sep 2015 10:16:04 +0530, Laxmikant Chitare wrote:
>>>
>>>> Hi,
>>>>
>>>> I know there is an elegant way to check if a given value is within
>>>> certain range.
>>>> Example - To check if x is between zero and ten, I can do 0 < x 10.
>>>>
>>>> Is there any similar elegant way to check if a value is out of certain
>>>> range?
>>>> Example - To check if x is either less than zero or greater than ten?
>>>> Right now I am using x < 0 or x > 10.
>>>>
>>>> Regards,
>>>> Laxmikant
>>>
>>> not (0 <= x <= 10)
>>>
>>
>> Yuck.
>>
>> --
>> My fellow Pythonistas, ask not what our language can do for you, ask
>> what you can do for our language.
>>
>> Mark Lawrence
>
> What is so "yuck" about that?  What would you do instead?  It seems like the best solution to me.  Easy to read, fast to execute.
>

I have to parse those damn brackets and then figure out the inverted 
logic. Give me x < 0 or x > 10 any day of the week.  When you're an old, 
senile git like me, readability counts :-)

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

#97296

On Thu, 1 Oct 2015 08:31 am, Mark Lawrence wrote:

>> What is so "yuck" about that?  What would you do instead?  It seems like
>> the best solution to me.  Easy to read, fast to execute.
>>
> 
> I have to parse those damn brackets and then figure out the inverted
> logic. Give me x < 0 or x > 10 any day of the week.  When you're an old,
> senile git like me, readability counts :-)

With the greatest of respect Mark, I don't believe that for a second. Your
sig line, which you have used without fail for more years than I can
remember includes the phrase "ask not what our language can do for you". If
you can understand that, I don't believe that you cannot figure out how to
go from this:

# x is within the range a to b
a <= x < = b

to this:

# x is NOT within the range a to b
not a <= x < = b


You're certainly a senile old git if you think we're falling for that
one :-)



P.S. in case you missed it, you don't actually need the params, since the
precedence of not is lower than the other operators.



Did-I-include-sufficient-smileys-ly y'rs,


-- 
Steven

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

#97297

In <560d78e2$0$1618$c3e8da3$5496439d@news.astraweb.com> Steven D'Aprano <steve@pearwood.info> writes:

> > I have to parse those damn brackets and then figure out the inverted
> > logic. Give me x < 0 or x > 10 any day of the week.  When you're an old,
> > senile git like me, readability counts :-)

> With the greatest of respect Mark, I don't believe that for a second. Your
> sig line, which you have used without fail for more years than I can
> remember includes the phrase "ask not what our language can do for you". If
> you can understand that, I don't believe that you cannot figure out how to

Certainly we can understand it.  But it takes ever-so-slightly more effort
to do so.

-- 
John Gordon                   A is for Amy, who fell down the stairs
gordon@panix.com              B is for Basil, assaulted by bears
                                -- Edward Gorey, "The Gashlycrumb Tinies"

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

#97301

On Fri, 2 Oct 2015 04:20 am, John Gordon wrote:

> In <560d78e2$0$1618$c3e8da3$5496439d@news.astraweb.com> Steven D'Aprano
> <steve@pearwood.info> writes:
> 
>> > I have to parse those damn brackets and then figure out the inverted
>> > logic. Give me x < 0 or x > 10 any day of the week.  When you're an
>> > old, senile git like me, readability counts :-)
> 
>> With the greatest of respect Mark, I don't believe that for a second.
>> Your sig line, which you have used without fail for more years than I can
>> remember includes the phrase "ask not what our language can do for you".
>> If you can understand that, I don't believe that you cannot figure out
>> how to
> 
> Certainly we can understand it.

Unless every single one of you (the "we" you refer to) are called Mark, I
don't believe I was talking to you :-P


> But it takes ever-so-slightly more effort 
> to do so.

Slightly more effort than what alternative? How would you communicate the
idea of *not* asking for X without using the concept of "not"?



-- 
Steven

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

#97303

In <560d8726$0$1602$c3e8da3$5496439d@news.astraweb.com> Steven D'Aprano <steve@pearwood.info> writes:

> > But it takes ever-so-slightly more effort to do so.

> Slightly more effort than what alternative? How would you communicate the
> idea of *not* asking for X without using the concept of "not"?

I wasn't commenting directly to the "ask not..." quote; I was referring
upthread to the choice between

    not 0 <= x <= 10

and

    x < 0 or x > 10

Both are of course understandable, but in my opinion, the latter one takes
slightly less effort to grok.

-- 
John Gordon                   A is for Amy, who fell down the stairs
gordon@panix.com              B is for Basil, assaulted by bears
                                -- Edward Gorey, "The Gashlycrumb Tinies"

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

#97305

John Gordon <gordon@panix.com>:

> I wasn't commenting directly to the "ask not..." quote; I was
> referring upthread to the choice between
>
>     not 0 <= x <= 10
>
> and
>
>     x < 0 or x > 10
>
> Both are of course understandable, but in my opinion, the latter one
> takes slightly less effort to grok.

Wouldn't

   x < 0 or 10 < x

be even more visual?


Marko

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

#97307

On 10/1/2015 12:59 PM, Marko Rauhamaa wrote:
> John Gordon <gordon@panix.com>:
>
>> I wasn't commenting directly to the "ask not..." quote; I was
>> referring upthread to the choice between
>>
>>      not 0 <= x <= 10
>>
>> and
>>
>>      x < 0 or x > 10
>>
>> Both are of course understandable, but in my opinion, the latter one
>> takes slightly less effort to grok.
>
> Wouldn't
>
>     x < 0 or 10 < x
>
> be even more visual?

Well, I had to parse that one twice to grok it.

Emile

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

#97312

In <87r3le1ht3.fsf@elektro.pacujo.net> Marko Rauhamaa <marko@pacujo.net> writes:

> > I wasn't commenting directly to the "ask not..." quote; I was
> > referring upthread to the choice between
> >
> >     not 0 <= x <= 10
> >
> > and
> >
> >     x < 0 or x > 10
> >
> > Both are of course understandable, but in my opinion, the latter one
> > takes slightly less effort to grok.

> Wouldn't

>    x < 0 or 10 < x

> be even more visual?

I don't know what you mean by "more visual".

In my opinion, when comparing a variable to a constant, it's more natural
to have the variable on the left and the constant on the right, so that's
one strike against this code.

Another strike is that the code isn't consistent with itself; it puts the
variable on the left in the first comparison, then swaps to the right for
the second comparison.

-- 
John Gordon                   A is for Amy, who fell down the stairs
gordon@panix.com              B is for Basil, assaulted by bears
                                -- Edward Gorey, "The Gashlycrumb Tinies"

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

#97314

On Thu, Oct 1, 2015 at 3:45 PM, John Gordon <gordon@panix.com> wrote:
> In <87r3le1ht3.fsf@elektro.pacujo.net> Marko Rauhamaa <marko@pacujo.net> writes:
>> Wouldn't
>
>>    x < 0 or 10 < x
>
>> be even more visual?
>
> [SNIP]
>
> Another strike is that the code isn't consistent with itself; it puts the
> variable on the left in the first comparison, then swaps to the right for
> the second comparison.

And on the other hand, it consistently uses the < operator rather
than swapping to > for the second comparison.

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

#97319

On Thu, Oct 1, 2015 at 3:03 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Thu, Oct 1, 2015 at 3:45 PM, John Gordon <gordon@panix.com> wrote:
> > In <87r3le1ht3.fsf@elektro.pacujo.net> Marko Rauhamaa <marko@pacujo.net> writes:
> >> Wouldn't
> >
> >>    x < 0 or 10 < x
> >
> >> be even more visual?
> >
> > [SNIP]
> >
> > Another strike is that the code isn't consistent with itself; it puts the
> > variable on the left in the first comparison, then swaps to the right for
> > the second comparison.
>
> And on the other hand, it consistently uses the < operator rather
> than swapping to > for the second comparison.

I would argue that the former consistency is more important than the
second, mostly because my mode of thought is along the lines of:
- Do I have more than 10 apples? (x > 10) or
- Do I have fewer than 10 apples? (x < 10)
rather than
- Is 10 fewer apples than I have? (10 < x) or
- Is 10 more apples than I have? (10 > x)

Because the former set is how I think, the former set is the easier to
understand. By no means does it mean I cannot understand the later
set, but it takes more thought to parse the meaning.

If a bunch of code consistently used the second, my mind would adapt
to more easily parse it, but it would take a while to transition
between the sets, especially compared to transitioning within a set.

Chris

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

#97326

On Thu, Oct 1, 2015 at 3:45 PM, John Gordon <gordon@panix.com> wrote:
> In <87r3le1ht3.fsf@elektro.pacujo.net> Marko Rauhamaa <marko@pacujo.net> writes:
>
>> > I wasn't commenting directly to the "ask not..." quote; I was
>> > referring upthread to the choice between
>> >
>> >     not 0 <= x <= 10
>> >
>> > and
>> >
>> >     x < 0 or x > 10
>> >
>> > Both are of course understandable, but in my opinion, the latter one
>> > takes slightly less effort to grok.
>
>> Wouldn't
>
>>    x < 0 or 10 < x
>
>> be even more visual?
>
> I don't know what you mean by "more visual".

Visually, it places the x outside the range suggested by 0 and 10,
similarly to how 0 <= x <= 10 places the x inside.

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

#97368

On Fri, 2 Oct 2015 07:45 am, John Gordon wrote:

> In <87r3le1ht3.fsf@elektro.pacujo.net> Marko Rauhamaa <marko@pacujo.net>
> writes:
[...]
>> Wouldn't
> 
>>    x < 0 or 10 < x
> 
>> be even more visual?
> 
> I don't know what you mean by "more visual".
> 
> In my opinion, when comparing a variable to a constant, it's more natural
> to have the variable on the left and the constant on the right, so that's
> one strike against this code.
> 
> Another strike is that the code isn't consistent with itself; it puts the
> variable on the left in the first comparison, then swaps to the right for
> the second comparison.

The alternative is equally inconsistent: for one comparison it uses less
than, for the other it uses greater than.


I find this discussion about the relative readability of 

not 0 <= x <= 10  #1

versus 

0 < x or x > 10  #2
0 < x or 10 < x

to be a good example of people's propensity to invent so-called "rational"
justifications for irrational preferences. Honestly, all these people
claiming that reading #1 takes them "slightly more effort" than reading #2,
or vice versa. Really? You've done an objective test of this? I don't think
so.

We know from UI testing in other fields that people's *self-reported*
efficiency and their *actual* efficiency are almost completely
uncorrelated. Back in the DOS versus Macintosh days, when mice were new,
DOS users consistently reported that using a mouse was too slow and
inefficient compared to the keyboard, but actual objective measurements of
the time that they took to do tasks showed the opposite.

E.g. subjects were asked to do some task, using the keyboard and then again
using the mouse, and (let's say) it actually took them 3 minutes to do it
via keyboard and 2 minutes via mouse, they reported that using the keyboard
commands was much more efficient, fast and easy.

Whether you have #1 or either variation of #2, the time it takes to read and
comprehend the expression is likely to be of the order of a few dozen
milliseconds, plus or minus a few dozen milliseconds. I expect the
variation will be nearly as great as the average time. (But of course, I
haven't done objective studies either.)

Anyone who has done high-school level maths should be familiar with the
notation `0 <= x <= 10`, read as "x between 0 and 10". (Anyone who is not
can hardly claim to be fluent in Python -- that's like claiming to be
fluent in English while not knowing where and how to use an exclamation
mark.)

If you want to check for the opposite, x not between 0 and 10, the natural
way to do so is with `not`: `not 0 <= x <= 10`. If you prefer `x < 0 or x >
10` for whatever reason, that's fine too. Some people prefer pizza, some
prefer kebabs... inventing (spurious) arguments of (imaginary) efficiency
("It takes me half a second less time to chew each mouthful of burger
compared to kebab") is unnecessary. But we do love the argument from
efficiency.

Frankly, as a profession, we programmers are lousy at prioritising. We write
pages and pages of convoluted, inconsistent, hard to understand code that
can sometimes take hours or even days to comprehend well enough to make
even a minor change, while spending dozens of person-hours arguing about
which expression saves them a microsecond or two of reading time. Yay us!



-- 
Steven

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

#97369

On 03/10/2015 11:29, Steven D'Aprano wrote:
> On Fri, 2 Oct 2015 07:45 am, John Gordon wrote:

> I find this discussion about the relative readability of
>
> not 0 <= x <= 10  #1
>
> versus
>
> 0 < x or x > 10  #2
> 0 < x or 10 < x
>
> to be a good example of people's propensity to invent so-called "rational"
> justifications for irrational preferences. Honestly, all these people
> claiming that reading #1 takes them "slightly more effort" than reading #2,
> or vice versa. Really?

I find #1 straightforward (although I'm bothered by the lack of 
parentheses as I would parse that as (not 0). Presumably, this does 
actually mean not (0<=x<=10).)

But I spent a minute looking at #2, and I'm still not sure that it 
expresses the same thing. I would have written #2 as:

  x<0 or x>10

-- 
Bartc

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

#97373

Actually, the fact that adults have more difficulty processing
negations is one of the earliest things proven experimentally
in experimental psychology.

Clark, H., & Chase, W. (1972). On the process of comparing sentences against pictures. Cognitive Psychology, 3, 472–517.

is one of the most heavily cited experiments in the field.

The question is _why_?

The early assumption was that the negation is conceptually more
difficult.  People think logically, and a negation is a harder
sentence to construct.

Recently, this idea has come to be questioned:
see
http://www.google.se/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CB0QFjAAahUKEwisvv_6lKbIAhXo8XIKHX32BKE&url=http%3A%2F%2Flangcog.stanford.edu%2Fpapers_new%2Fnordmeyer-2015-underrev.pdf&usg=AFQjCNEaPmluLtZs6aeAHgnyCCLEDazJdg

which I shortened to:
http://bit.ly/1OOfK46

It seems that people tend to hear what they expect to hear, and that
effect overwhelms any 'this is harder to constuct logically' effect.

Also, the 'mouse is quicker' experiment was rather more nuanced than
you reported.  It seems when measuring 'what is faster' the cognitive
load is important.  Time seems to go faster when you are thinking
harder about something, than when you are not.  (i.e. how did my
coffee get cold?  I just started hacking on this thing?)  It seems
that mouse editing was less of a cognitive load than typing, for
the people studied, thus they reported that keyboard was faster,
when it wasn't for them.

But

the experiment was replicated among secretaries who had superior typing
skills (and used emacs a lot).  For a lot of them, moving text by mouse
was not faster than using keyboard macros.  But the limiting factor
seemed to be 'how hard did I have to think about it' -- if you move
things by keyboard macro without thinking, then you won't report that
it takes you time, and you won't accurately report how long it takes
to do the task.

Thus for this experiment, the conclusion was that people were a whole
lot better at telling 'how hard did this make me think' than 'how
long did it take me to do the job'.  

Also, when you changed the requirements to 'reformat text all day long'
a huge number of people could get a lot more work done using emacs than
using the mouse editor.

We ran  both of these experiemnts in the coputer graphics lab at the
University of Toronto as a joint csc/psych exp in the mid 1980s, and
our conclusion at the time was that, for 'all day long' sorts of
tasks what was most important was boredom.  Once the subject got
bored with the task, it took longer.

For me the experiment was wonderful for another reason.  The
University of Toronto has long believed that their secretaries weren't
intelligent enough to use emacs, and had gone to particular effort to
design an easier editor for them to use.  But the secretaries of
the Political Science department, who used to come down to the
department of Zoology (where I worked) to use our pdp-11/44 for
text formating, and me (the undergraduate they hired to help
Zoologists format their graduate theses prior to having them
phototypeset) for advice, once saw me fix a problem by writing an
emacs macro, and hauling their document into emacs and using it.

They were entranced.  And wondered if I could teach them how to do it.
I thought, fine enough, and so taught classes in how to use emacs to
about 6 of them for 3 nights a week one summer.

And it turned out that everybody, including one sweet lady whose powers
of reasoning was seriously sub par, learned how to use emacs.  She learned
mostly by rote, but she could do it.  And the first two weeks of learning
how to write macros was very hard.  I learned a lot about how not to
teach things in that class. :)  So a good bit of the problem was lack
of skill in the teacher.

But once we started on writing them for real life tasks they had, and
not useless contrived examples I came up with, it went a lot better.
And soon they were quite proficient, and Political Science had its own
set of common emacs macros.

I got a real understanding of how much 'retype it by hand, it is
faster' you do, if your normal rate of typing is 165 wpm or more.
Especially if you grew up with paper, not computers, where retyping it
was considered very normal ...

At any rate when I heard about this experiment I got the secretaries
to compete, for fun.  The secretaries with their own emacs macros beat
the heck out of everybody else at 'copying and moving text around',
which was, after all, something they did all of the time.

The researchers thought that this wasn't a fair test, as the playing
field was so far from level.  The secretaries thought they could
better their score if they had been given the task the night before --
as they would have designed an even better emacs macro.  And, of course,
if they had a lot of that particular task to do, they would have
'had Caroline write one and teach it to us', as was usual.

Which got people down to the heart of the matter.  People wanted to
measure keyboard vs mouse efficiency, but as far as the secretaries
were concerned any test done 'for fun' didn't measure up to their real
lives, where getting more throughput meant 'we don't have to work
overtime' and 'only one secretary works in the office Friday after
3:30 in case a professor needs something typed up in a hurry, the
rest of us go home early'.

They were fairly hostile to the idea of inflicting the mouse editor
on the university support staff, unless it came with emacs lisp built
in.  And there was considerable 'when you pry my emacs away from my
cold dead fingers' sentiment.

These days, I suspect, the Political Science professors at U of T
do their own typing.  The profession of typist seems to be nearly
extinct.  And voice-to-text is the next big thing.

But we already know that many people find talking for a long time
itself unpleasant and exhausting.  I like my email.  I hate listening
to voice messages.  But, should we all live long enough, will
listening to people become the only option?

Laura

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

#97375

On Sat, 3 Oct 2015 10:12 pm, Laura Creighton wrote:

> People think logically


LOL :-)



-- 
Steven

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

#97376

> On Sat, 3 Oct 2015 10:12 pm, Laura Creighton wrote:
> 
> > People think logically
> 
> 

When I see, Python and its Unicode implementation,
I doubt.
Except that in that case, it is *really* logically buggy.

jmf

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

#97392

On Sat, 3 Oct 2015 10:12 pm, Laura Creighton wrote:

> Actually, the fact that adults have more difficulty processing
> negations is one of the earliest things proven experimentally
> in experimental psychology.

I don't think I've questioned that under some circumstances some negations
can be hard to understand. I've certainly written my share of code
involving negatives that I've had to refactor to understand. A typical
example:

def function(arg, dontpreprocess=False):
    """Perform function on arg. If dontpreprocess is not true, 
    arg is preprocessed."""
    if not dontpreprocess:
        arg = preprocess(arg)
    ...

And of course there are the legendary chains of negations:

don't not cancel the preprocessor suppressor

Does the preprocess run or not? :-)

But I don't think we can jump from a general observation about negations to
the conclusion that a logical disjunction of two different comparisons is
necessarily easier to understand than a negated chained comparison. Some
negations are easy to understand:

    Don't touch that!

and some negations may technically be harder to understand, but in a
practical sense the difference may be negligible:

    if x == 1: ...

    if x != 1: ...


I refuse to believe that the second is *significantly* harder to reason
about than the first.


[...]
> It seems that people tend to hear what they expect to hear, and that
> effect overwhelms any 'this is harder to constuct logically' effect.

I can certainly believe that. It explains a class of errors:

"I'll have the cheese and salad sandwich, no butter, no salt or pepper."

"Okay." [proceeds to make sandwich with butter, salt and pepper]


I've had that happen to me more times than I can remember. People only
listen with half an ear, especially if they're tired, distracted,
emotional, bored, busy, or breathing.

 
> Also, the 'mouse is quicker' experiment was rather more nuanced than
> you reported.  It seems when measuring 'what is faster' the cognitive
> load is important.  Time seems to go faster when you are thinking
> harder about something, than when you are not.  (i.e. how did my
> coffee get cold?  I just started hacking on this thing?)  It seems
> that mouse editing was less of a cognitive load than typing, for
> the people studied, thus they reported that keyboard was faster,
> when it wasn't for them.

Thanks for the anecdote, it was fascinating.

My point was not so much about the advantage (if any) of mouse over
keyboard, which I'm sure will depend on a multitude of factors, but of
people's ability to judge their own efficiency, which I maintain is often
not very good.



-- 
Steven

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web