If a 1 offset under the system the guy advocates means what a 0 normally does, that implies that a +1 vote means the same thing as a +0 vote. So Guido is "agreeing" that it deserves +1, but only if you use 1-indexing so +1 is the lowest possible vote.
But +0 isn't the lowest possible vote in the current system... unless you want to claim that -1 is the highest possible vote because it wraps to the top of the scale.
(not to post something useless, but I'm literally speechless going back and forth between "that's so awesome" and "that's so dumb" in my head for so many different reasons)
(and at how short and quick Guido's response was, as if it was such an easy decision to make.)
I am truly, truly horrified that this a language option in perl, although I'm not surprised. (Well, I did google it to see if you were joking, but you weren't, apparently).
The older I get the more Larry Wall strikes me as like a really well intentioned hippy type; when in God's green earth has it been a good idea to allow a five character statement change the truth values of nearly every for loop in a body of code?
Perl always claimed it gave you enough rope to hang yourself, but this goes far, far beyond that. This is like building the scaffolding and marking it like "Young developers, play here! Ropes are fun!"
ctypes is like god-mode for Python... I like your hack too. I just play around with it from time to time, I believe the only "serious" thing I've done with it so far is making a Python interface around a C library I made.
#defining reserved words is not permitted by standard C (or C++), although compilers do allow it in practice. Anyway, it's a totally different thing to abuse a general-purpose feature to do horrible thing X than to have a specific feature, only useful for doing horrible things, built into the language.
1) It's not like the docs don't recommend against it.
2) As of Perl 5+ it's evaluated at compile-time rather than run-time, which is not as bad as if you could flip back and forth at runtime. Though you can use 'local' to lexically scope its effects -- hilarity ensues as you hand off said code to someone else for maintenance.
3) It's from a different era. As per the docs:
Default is 0, but you could theoretically set
it to 1 to make Perl behave more like awk (or
Fortran)
It's there to help you emulate awk or Fortran... definitely targeted at today's young programmers. ;-)
[ Though the core of SciPy/NumPy is notably written in Fortran. Not quite as dead as some would have you believe. ]
Apologies if this appears dumb. After going through the link I still could not understand why is it ok to exclude the upper bound while including the lower bound? Is it because the lower bound is fixed as 0 is the smallest natural number? Or is there some other reason.
Dijkstra explains it pretty clearly - there are two main reasons.
The first is so that the number of elements in the array/list/vector/collection is given by upper-lower.
The second is so that successive intervals re-use the same number, the upper bound of one becoming the lower bound of the next.
This is python we can have:
L[:3], L[3:6], L[6:23], L[23:40], L[40:]
With the repeated numbers we know that all elements of L have been included. Further, we know that given:
L[start:end]
... then (provided L had at least "end" elements to start with) the resulting length is end-start. If you included the end point then the length would be end-start+1 which is fertile ground for fence-post errors.
But both of those things would be true if you include the upper bound and don't include the lower bound. I.e. if an array with bounds 0 and 4 had items in positions 1, 2, 3, and 4.
Yes, and that question is covered in the Dijkstra paper.
If you're talking about numbers from 13 onwards, it doesn't really make sense to talk about numbers greater than 12. More specifically, if you start counting from 0 then it feels (to me) more natural to include the lower bound.
If you talk about {5 .. 13} then it feels easier to say
"From 5 up to (but not including) 13,"
rather than saying
"From 5, er, sorry, no, from *6* up to and including 13."
There is a question of taste here, as well as background and experience. Don't expect it to be "objectively proven."
In the end it is all about convention, and what ends up making code cleaner, less error-prone, and more aesthetically pleasing. As I say, there are questions of taste and experience. Personally I find the Dijkstra/Python method for more consistent and pleasing than the alternatives.
Another reason: Wrap-around with modular reduction is a snug fit, so it's L[i % n] rather than L[1 + i % n]. You could have taken 1, 2, ..., n or indeed any set of n integers with distinct residue classes modulo n as the representatives, but the standard choice in mathematics is 0, 1, ..., n-1 for consistency with the division theorem.
It is often very inconvenient when mathematicians number from 1 instead of 0. A classic example is with Fourier matrices. Let w be a primitive nth root of unity. Then numbering as computer scientists, starting with 0, the formula is F(i,j) = w^(i j). But using the mathematician's convention, it is F(i,j) = w^((i-1)(j-1)). The same issue exists with all Vandermonde matrices.
Roberto Ierusalimschy has an interesting perspective on the zero vs. one concept:
"Because people count from one, not zero.
We do that in kindergarten, in music, when starting a race, when drawing up an agenda, everywhere. One, two, three, etc have their counterparts in every known language on earth.
Zero, on the other hand, is an advanced concept. Humanity could prove that sqrt(2) is not a rational number centuries before anybody thought that a symbol for zero might be useful.
A harder question would be "why do arrays in some other languages count from zero not one?" The answer for C is a good one: "so that * (A+k) and A[k] mean the same". For Python, the answer seems to be "because it's that way in C"."
And:
"Currently, many languages are 0-based due to influence from C. Ironically, none of them share the reason that made C 0-based (where a[e] means * (a+e))."
(EDIT: I had to add spaces after the stars to prevent HN from italicizing a huge block of text.
Meanwhile, some people do count up from zero. At least in numbering floors in a building. I know in Europe and other parts of the world the ground floor is the zeroth floor, and it goes up from there.
Yeah, a lot of the buildings at my university are numbered that way. But not even in Europe would one count a stack of paper as "zero, one, two, three..."
Numerically, yes, but nobody calls it a "zeroth" floor. Rather, its "ground", "first", "second" (or G, 1, 2, 3...) so while ground is equivalent to zero, nobody actually says (or thinks) zero. At least, nowhere I've been.
Where I work, rooms on the 1st floor have numbers like 1.01, 1.02 etc., on the ground floor it's 0.01, 0.02 etc., and in the basement it's -1.01, -1.02 etc.
This is confusing for some people (unfamiliar with the situation), who need to go to a number in the basement but consistently turn up two floors higher.
A chromatic approach uses a 0-indexed system while the classical diatonic scales and intervals are indexed at 1. A perfect 5th is a chromatic interval of 7 semitones.
I consider _counting_ and _indexing_ being two different concepts. In C, you declare int a[5], where 5 is the array size (element _count_), but its _indices_ run from 0 to 4. (Indeed, an array of size n can be also viewed as a _function_ with domain [0,n-1].)
(And to those taking the thread seriously: this is all in jest. We
won't change the indexing base. The idea is so preposterous that the
only kind of response possible is to laugh with it.)
Well, given Guido's endorsement, I think we need to change how these +1/-1
votes work. Clearly, +1 means what +0 used to mean. So you have to say +2 to
vote in favor of something and -0 to vote against. I know it will be
confusing during the transition period but it will be so much easier to use
when we are done.
52 comments
[ 5.8 ms ] story [ 104 ms ] thread(not to post something useless, but I'm literally speechless going back and forth between "that's so awesome" and "that's so dumb" in my head for so many different reasons)
(and at how short and quick Guido's response was, as if it was such an easy decision to make.)
edit: also found this later in the thread to confirm the humor behind everything: http://mail.python.org/pipermail/python-ideas/2011-September...
The older I get the more Larry Wall strikes me as like a really well intentioned hippy type; when in God's green earth has it been a good idea to allow a five character statement change the truth values of nearly every for loop in a body of code?
Perl always claimed it gave you enough rope to hang yourself, but this goes far, far beyond that. This is like building the scaffolding and marking it like "Young developers, play here! Ropes are fun!"
How about this in C(and thousand others): #define if while
I am pretty sure I can find something to horrify you in almost any language.
Here's a small snippet that let you add methods to built-ins:
I think I discovered the hack when I found out about the id() function, and hex(id(5)) looked suspiciously like a pointer value. (And http://docs.python.org/library/functions.html#id confirms.) http://docs.python.org/library/ctypes.html has usually been pretty useful. Apart from that, just play.
2) As of Perl 5+ it's evaluated at compile-time rather than run-time, which is not as bad as if you could flip back and forth at runtime. Though you can use 'local' to lexically scope its effects -- hilarity ensues as you hand off said code to someone else for maintenance.
3) It's from a different era. As per the docs:
It's there to help you emulate awk or Fortran... definitely targeted at today's young programmers. ;-)[ Though the core of SciPy/NumPy is notably written in Fortran. Not quite as dead as some would have you believe. ]
Few people seem to know that we have real and valid reasons for indexing from 0 instead of 1.
The first is so that the number of elements in the array/list/vector/collection is given by upper-lower.
The second is so that successive intervals re-use the same number, the upper bound of one becoming the lower bound of the next.
This is python we can have:
With the repeated numbers we know that all elements of L have been included. Further, we know that given: ... then (provided L had at least "end" elements to start with) the resulting length is end-start. If you included the end point then the length would be end-start+1 which is fertile ground for fence-post errors.If you're talking about numbers from 13 onwards, it doesn't really make sense to talk about numbers greater than 12. More specifically, if you start counting from 0 then it feels (to me) more natural to include the lower bound.
If you talk about {5 .. 13} then it feels easier to say
rather than saying There is a question of taste here, as well as background and experience. Don't expect it to be "objectively proven."http://www.paulgraham.com/taste.html
In the end it is all about convention, and what ends up making code cleaner, less error-prone, and more aesthetically pleasing. As I say, there are questions of taste and experience. Personally I find the Dijkstra/Python method for more consistent and pleasing than the alternatives.
It is often very inconvenient when mathematicians number from 1 instead of 0. A classic example is with Fourier matrices. Let w be a primitive nth root of unity. Then numbering as computer scientists, starting with 0, the formula is F(i,j) = w^(i j). But using the mathematician's convention, it is F(i,j) = w^((i-1)(j-1)). The same issue exists with all Vandermonde matrices.
"Because people count from one, not zero.
We do that in kindergarten, in music, when starting a race, when drawing up an agenda, everywhere. One, two, three, etc have their counterparts in every known language on earth.
Zero, on the other hand, is an advanced concept. Humanity could prove that sqrt(2) is not a rational number centuries before anybody thought that a symbol for zero might be useful.
A harder question would be "why do arrays in some other languages count from zero not one?" The answer for C is a good one: "so that * (A+k) and A[k] mean the same". For Python, the answer seems to be "because it's that way in C"."
And:
"Currently, many languages are 0-based due to influence from C. Ironically, none of them share the reason that made C 0-based (where a[e] means * (a+e))."
(EDIT: I had to add spaces after the stars to prevent HN from italicizing a huge block of text.
This is confusing for some people (unfamiliar with the situation), who need to go to a number in the basement but consistently turn up two floors higher.
Music uses both systems.
A chromatic approach uses a 0-indexed system while the classical diatonic scales and intervals are indexed at 1. A perfect 5th is a chromatic interval of 7 semitones.
1-do(0) 2-re(2) 3-me(4) 4-fa(5) 5-sol(7) 6-la(9) 7-ti(11)
The question is whether it's more useful to count the notes that appear and label them with numbers, or to measure the difference between them.
For example, imagine I want to fake an nm 2d matrix M with an array A, with nm elements
Then with 0-indexing, M[i][j] is stored at A[im+j]. With 1-indexing, M[i][j] is stored at A[(i-1)m+j].
(And to those taking the thread seriously: this is all in jest. We won't change the indexing base. The idea is so preposterous that the only kind of response possible is to laugh with it.)
--Guido
http://mail.python.org/pipermail/python-ideas/2011-September...
Loved this response http://mail.python.org/pipermail/python-ideas/2011-September...