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

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

Newbie: The philosophy behind list indexes

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

Contents

  Newbie: The philosophy behind list indexes ian.l.cameron@gmail.com - 2013-06-14 22:21 -0700
    Re: Newbie: The philosophy behind list indexes Chris Rebert <clp2@rebertia.com> - 2013-06-14 22:35 -0700
    Re: Newbie: The philosophy behind list indexes Chris Angelico <rosuav@gmail.com> - 2013-06-15 15:49 +1000
    Re: Newbie: The philosophy behind list indexes Peter Otten <__peter__@web.de> - 2013-06-15 08:42 +0200
    Re: Newbie: The philosophy behind list indexes John Ladasky <john_ladasky@sbcglobal.net> - 2013-06-15 00:19 -0700
    Re: Newbie: The philosophy behind list indexes Olive <not0read0765@yopmail.com> - 2013-06-15 09:44 +0200
    Re: Newbie: The philosophy behind list indexes ian.l.cameron@gmail.com - 2013-06-19 13:46 -0700

#48248 — Newbie: The philosophy behind list indexes

I bet this is asked quite frequently, however after quite a few hours searching I haven't found an answer.

What is the thinking behind stopping 'one short' when slicing or iterating through lists?

By example;

>>> a=[0,1,2,3,4,5,6]
>>> a
[0, 1, 2, 3, 4, 5, 6]
>>> a[2:5]
[2, 3, 4]

To my mind, it makes more sense to go to 5. I'm sure there's a good reason, but I'm worried it will result in a lot of 'one-off' errors for me, so I need to get my head around the philosophy of this behaviour, and where else it is observed (or not observed.)

I'm just a hobbyist who likes to learn things, and the Raspberry Pi has me interested in Python. I have dabbled in QB, VB, Spin (Parallex), Bascom, and Arduino's in the past.

Thanks for your insights!

Ian.

[toc] | [next] | [standalone]

#48250

[Multipart message — attachments visible in raw view] — view raw

On Jun 14, 2013 10:26 PM, <ian.l.cameron@gmail.com> wrote:
> I bet this is asked quite frequently, however after quite a few hours
searching I haven't found an answer.
>
> What is the thinking behind stopping 'one short' when slicing or
iterating through lists?
>
> By example;
>
> >>> a=[0,1,2,3,4,5,6]
> >>> a
> [0, 1, 2, 3, 4, 5, 6]
> >>> a[2:5]
> [2, 3, 4]
>
> To my mind, it makes more sense to go to 5. I'm sure there's a good
reason, but I'm worried it will result in a lot of 'one-off' errors for me,
so I need to get my head around the philosophy of this behaviour, and where
else it is observed (or not observed.)

I find Dijkstra's explanation rather convincing:
http://www.cs.utexas.edu/~EWD/transcriptions/EWD08xx/EWD831.html

Cheers,
Chris

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

#48252

On Sat, Jun 15, 2013 at 3:21 PM,  <ian.l.cameron@gmail.com> wrote:
> What is the thinking behind stopping 'one short' when slicing or iterating through lists?
>
> By example;
>
>>>> a=[0,1,2,3,4,5,6]
>>>> a
> [0, 1, 2, 3, 4, 5, 6]
>>>> a[2:5]
> [2, 3, 4]
>
> To my mind, it makes more sense to go to 5. I'm sure there's a good reason, but I'm worried it will result in a lot of 'one-off' errors for me, so I need to get my head around the philosophy of this behaviour, and where else it is observed (or not observed.)


There are two equally plausible ways to identify positions in a
list/string/whatever. One is to number the elements, the other to
number the gaps between them. I'll try my hand at some ASCII art... be
sure to view this in a monospaced font.


[  0  ,  1  ,  2  ,  3  ,  4  ,  5  ,  6  ]
|     |     |     |     |     |     |     |
0     1     2     3     4     5     6     7
-7   -6    -5    -4    -3    -2    -1    (0)

When you ask for the slice from 2 to 5, you get the elements between
those slot markers. That's [2,3,4].

When you ask for negative indices, the same applies, only there's no
parallel way to ask for negative 0 aka end of list. [1]

>>> a[2:-2]
[2, 3, 4]

There are a number of reasons for working this way. For instance, the
length of the range a[x:y] is simply y-x, negative indices aside. It's
even more significant when you look at something that doesn't have
discrete units - such as times.

Suppose you invent a data type to represent a time range. You might
describe a TV show as lasting from 10:00 till 10:30; but what do you
really mean by those times? Do you mean from the start of 10:00 until
the end of 10:30? When is the end of 10:30? Is it the end of the
minute 10:30, the end of the second 10:30:00, the end of the
millisecond 10:30:00.000? Easier to describe it as the beginning of
that moment, because that has the same meaning regardless of your
resolution. You can always add more trailing zeroes to either the
start time or the end time, without changing the meaning of the range.

Same applies to generation of random numbers. If you have a function
that generates a random number uniformly in the range [0,1) - that is,
including 0 but not including 1 - and you multiply it by an integer
and truncate the decimal, you get a random integer uniformly in the
range [0,x), which is an extremely useful thing. You don't even need
to care what the actual range in the RNG is (does it produce 0.000
through 0.999, or 0.000000 through 0.999999?), as long as it's
significantly more than your target range. But if the RNG could return
1.0, then you need to deal with that possibility in your result, which
frankly isn't much use.

It takes some getting used to, perhaps, given that most people in the
real world work with closed ranges; but ultimately it makes far more
sense. And if it weren't for a huge case of lock-in, I would wish we
could change the way Scripture references are interpreted, for the
same reasons. Taking examples from tomorrow's church service, two of
the readings are Matthew 18:15-20 and Philippians 3:8-10. When you
look in a Bible, you'll find verse numbers preceding the verses (at
least, that's the convention in most editions). If the ranges were
written as half-open (eg Matt 18:15-21), it would be simply from verse
marker 15 to verse marker 21; and "to the end of the chapter" or "to
the end of the book" would have obvious notations (eg Matt 18:15-19:1
or Matt 27-Mark 1). Of course, this would make for a huge amount of
confusion, since the present system has been around for centuries...
but it would make more sense, so I'm very much glad it's the way
Python chose to do it :)

ChrisA

[1] You can use None or omit the index, but there's no "negative 0"
integer to use.

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

#48257

Chris Rebert wrote:

> On Jun 14, 2013 10:26 PM, <ian.l.cameron@gmail.com> wrote:

>> What is the thinking behind stopping 'one short' when slicing or
>> iterating through lists?

> I find Dijkstra's explanation rather convincing:
> http://www.cs.utexas.edu/~EWD/transcriptions/EWD08xx/EWD831.html

This is the only case where I prefer the pdf ;)

http://www.cs.utexas.edu/~EWD/ewd08xx/EWD831.PDF

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

#48262

On Friday, June 14, 2013 10:21:28 PM UTC-7, ian.l....@gmail.com wrote:
>I'm sure there's a good reason, but I'm worried it will result in a lot of 
>'one-off' errors for me, so I need to get my head around the philosophy of this
>behaviour, and where else it is observed (or not observed.)

My understanding is that it's so the same index can be used in slicing a list into complementary parts.  This also makes concatenation the inverse operation of slicing:


Python 3.3.1 (default, Apr 17 2013, 22:30:32) 
[GCC 4.7.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> a = list(range(10))
>>> a
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>>> a[:7]
[0, 1, 2, 3, 4, 5, 6]
>>> a[7:]
[7, 8, 9]
>>> a[:7] + a[7:]
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]


It's a logical extension of the start-indexing-at-zero issue, when you think about it.  Yes, you will make the occasional off-by-one error at first.  You'll get over it.

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

#48264

On 15/06/13 07:21, ian.l.cameron@gmail.com wrote:
>
> I bet this is asked quite frequently, however after quite a few hours searching I haven't found an answer.
>
> What is the thinking behind stopping 'one short' when slicing or iterating through lists?
>
> By example;
>
>>>> a=[0,1,2,3,4,5,6]
>>>> a
> [0, 1, 2, 3, 4, 5, 6]
>>>> a[2:5]
> [2, 3, 4]
>
> To my mind, it makes more sense to go to 5. I'm sure there's a good reason,
> but I'm worried it will result in a lot of 'one-off' errors for me, so I need to get my head around the philosophy
> of this behaviour, and where else it is observed (or not observed.)

I think it simplify some arithmetic. How many element contain a[2:5]? 
Answer 5-2=3. And a[:5] contain the first 5 elements.

Olive

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

#48750

Thanks everyone for taking the time to offer some very insightful replies. Learning a new language is so much more fun with a group of friendly and helpful people around!

[toc] | [prev] | [standalone]

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

csiph-web