Re: Python why questions
Russ P. russ.paie...@gmail.com wrote: However, I've switched from Python to Scala, so I really don't care. Really? Your endless whining in this thread would seem to indicate otherwise. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On Aug 23, 7:46 pm, alex23 wuwe...@gmail.com wrote: Russ P. russ.paie...@gmail.com wrote: However, I've switched from Python to Scala, so I really don't care. Really? Your endless whining in this thread would seem to indicate otherwise. Yes, I guess I care some, but not much. I still use Python for some things, and I still have lots of legacy Python code that I still use. I just like to whine about zero-based indexing (but Scala is no different in that regard). It's my number one gripe. (My number zero gripe is semicolons after each statement -- but both Python and Scala got that one right, thank goodness.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On Aug 21, 1:33 am, Steven D'Aprano st...@remove-this- cybersource.com.au wrote: On Fri, 20 Aug 2010 11:01:42 -0700, Russ P. wrote: Most programmers probably never use vectors and matrices, so they don't care about the inconsistency with standard mathematical notation. Perhaps you should ask the numpy programmers what they think about that. Why would I care in the least about something called numpy? Vectors and matrices are just arrays, and the suggestion that most programmers don't use arrays (or array-like objects like lists) is ludicrous. But the vast majority of arrays are not vectors or matrices in the mathematical sense. And the vast majority of programmers who use arrays have no clue about vectors and matrices in the mathematical sense. Ask your typical programmer what an SVD is. And yes, I understand that zero-based indexing can be slightly more efficient. That's why I think it's appropriate for low-level languages such as C. However, I think one-based indexing is more appropriate for high-level languages. Only if your aim is to reduce the learning curve for newbies and non- programmers, at the expense of making it easier for them to produce buggy code. If you're suggesting that one-based indexing makes it easier to produce buggy code, I think you must be smoking something. That's a defensible choice. I'm a great fan of Apple's Hypercard from the late 80s and early 90s, and it used one-based indexing, as well as English-like syntax like: Python is a high level language, and high-level languages have many features that make it easier for newbies as well as experienced programmers at the expense of extreme efficiency. But the array indexing in Python is a throwback to C: it is zero-based and uses square brackets. Say what you will, but both of those aspects just seem wrong and awkward to me. However, I've switched from Python to Scala, so I really don't care. You guys can have it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On Sun, Aug 22, 2010 at 12:23 AM, Russ P. russ.paie...@gmail.com wrote: On Aug 21, 1:33 am, Steven D'Aprano st...@remove-this- cybersource.com.au wrote: On Fri, 20 Aug 2010 11:01:42 -0700, Russ P. wrote: Most programmers probably never use vectors and matrices, so they don't care about the inconsistency with standard mathematical notation. Perhaps you should ask the numpy programmers what they think about that. Why would I care in the least about something called numpy? Because it's a popular matrix math package for Python. Its users are thus a subset of programmers which by definition don't fall into the most programmers group you describe. Cheers, Chris -- Google is your friend! http://blog.rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On 2010-08-21, Steven D'Aprano st...@remove-this-cybersource.com.au wrote: There is room in the world for programming languages aimed at non- programmers (although HC is an extreme case), but not all languages should prefer the intuition of non-programmers over other values. Extremer: Inform 7. -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On Aug 22, 12:47 am, Chris Rebert c...@rebertia.com wrote: On Sun, Aug 22, 2010 at 12:23 AM, Russ P. russ.paie...@gmail.com wrote: On Aug 21, 1:33 am, Steven D'Aprano st...@remove-this- cybersource.com.au wrote: On Fri, 20 Aug 2010 11:01:42 -0700, Russ P. wrote: Most programmers probably never use vectors and matrices, so they don't care about the inconsistency with standard mathematical notation. Perhaps you should ask the numpy programmers what they think about that. Why would I care in the least about something called numpy? Because it's a popular matrix math package for Python. Its users are thus a subset of programmers which by definition don't fall into the most programmers group you describe. Yes, I know what numpy is, and I'm sure it's great. I was just taking a light-hearted jab at the name. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On Fri, 20 Aug 2010 11:01:42 -0700, Russ P. wrote: Most programmers probably never use vectors and matrices, so they don't care about the inconsistency with standard mathematical notation. Perhaps you should ask the numpy programmers what they think about that. Vectors and matrices are just arrays, and the suggestion that most programmers don't use arrays (or array-like objects like lists) is ludicrous. And yes, I understand that zero-based indexing can be slightly more efficient. That's why I think it's appropriate for low-level languages such as C. However, I think one-based indexing is more appropriate for high-level languages. Only if your aim is to reduce the learning curve for newbies and non- programmers, at the expense of making it easier for them to produce buggy code. That's a defensible choice. I'm a great fan of Apple's Hypercard from the late 80s and early 90s, and it used one-based indexing, as well as English-like syntax like: put char 2 of the third word of it into the last field You don't need to know a thing about the language to guess what that does, and you'd probably be right. It would have been inappropriate for Hypercard to use zero-based indexing, because it was aimed at giving non- programmers a shallow learning curve and syntax that looks like natural language. There is room in the world for programming languages aimed at non- programmers (although HC is an extreme case), but not all languages should prefer the intuition of non-programmers over other values. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On Fri, 20 Aug 2010 09:21:25 +0200, Kai Borgolte wrote: Sorry about my previous posting with wrong references, this one should be better. Steven D'Aprano wrote: A simple example: Using zero-based indexing, suppose you want to indent the string spam so it starts at column 4. How many spaces to you prepend? As AK pointed out, I totally messed up the example by talking about column 4 then giving an example of column 5. Sigh. 0123456789 spam No, you won't want to indent a string so it starts at column 4. You simply want to indent the string by four spaces. Like in PEP 8: /Use 4 spaces per indentation level./ I don't see what PEP 8 has to do with anything here. Code is not the only thing that needs indenting, and 4 was just a mere example chosen at random. I might be pretty-printing a table of numbers, I might be drawing a text-based maze, I could be writing a function to left-fill strings with some arbitrary character, e.g left-fill with asterisks: 01234567 spam Besides, PEP 8 is merely a coding standard, not a law of nature. Some people might choose other coding standards, such as two-space indents, eight-spaces, or even (gasp! horror!) tabs. And of course your text editor will number the columns beginning with one, so the string starts at column 5. Ah, text editors. I'm glad you mention that... My text editor of choice is kwrite, which suits me fine, but it has one obnoxious, painful design choice. It indexes characters from one, so when I have the cursor at the left-hand margin and haven't typed anything, it says I'm at position 1. Consequently, if I want to know how many characters are in a line (and you'd be amazed how frequently I need to do this!), I can't just glance at the cursor position, I have to remember to subtract one from whatever the cursor position says. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
Russ P. wrote: A simple example: Using zero-based indexing, suppose you want to indent the string spam so it starts at column 4. How many spaces to you prepend? No, you won't want to indent a string so it starts at column 4. You simply want to indent the string by four spaces. Like in PEP 8: /Use 4 spaces per indentation level./ 0123456789 spam And of course your text editor will number the columns beginning with one, so the string starts at column 5. 123456789 spam -- Kai Borgolte, Bonn -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
Sorry about my previous posting with wrong references, this one should be better. Steven D'Aprano wrote: A simple example: Using zero-based indexing, suppose you want to indent the string spam so it starts at column 4. How many spaces to you prepend? No, you won't want to indent a string so it starts at column 4. You simply want to indent the string by four spaces. Like in PEP 8: /Use 4 spaces per indentation level./ 0123456789 spam And of course your text editor will number the columns beginning with one, so the string starts at column 5. 123456789 spam -- Kai Borgolte, Bonn -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On Thu, Aug 19, 2010 at 07:13:50PM +, Steven D'Aprano wrote: Mathematics is an ancient art that values tradition and convention. It doesn't matter how hard it was to come up with a proof, or how difficult to verify it. Mathematicians value logical correctness and some undefinable sense of elegance over how easy it is to verify, the readability of the notation, resistance to errors, and the ability of mediocre mathematicians to make useful contributions. Mathematical notation and conventions are not, by any stretch of the imagination, designed to reduce errors. Mathematicians consider it a good thing that they are still mostly using the same notation invented by (say) Leibniz. Another thing worth mentioning (I guess here is a good a place as any other) is the fact that programming and mathematics are still pretty different things, despite how much we programmers would like to think ourselves as some kind of mathematician. Fields-medal winners are not likely to be writing database applications in their spare time, or to save up money for blackboards and pencils. But mathematics is a wide field, and one area I'm very familiar in is signal processing, which has taken a lot of mathematics to make our algorithms work. In fact, of all electrical engineering disciplines, signal processing is probably the most mathematical. I find this thread extremely interesting, but what surprised me that everyone seems to agree that mathematics is 1-based, but we Pythoneers should stick to zero-based. I disagree. To make sure I'm not going crazy, I took the top five books lying on my desk, which were the DSP book by Oppenheim/Schafer, two books by Stephen M. Kay (Spectral Estimation and Estimation Theory) and the Channel Coding book by Lin Costello. This is isn't pure mathematics (as in proving the Goldbach conjecture), but nevertheless, this is serious mathematics and, surprise, they most exclusively use zero-based notation. You probably don't have those books in grabbing distance, so here's some examples for zero-based stuff: - The definition of the FFT and one-sided z-transform (practically everywhere I've seen) - Time indices for time-discrete signals usually start at 0 for causal signals, same goes for filters (impulse responses) - Vector representation of polynomials - The Levinson-Durbin recursion algorithm is way more readable with zero-based indices (step 0 is an initialisation step) - Even most matrices used in the context for coding use zero-based indexing (i.e., the left-most column is column zero). I would like to add that dealing with linear algebra in GF2 is a bit different from handling complex signals as in the previous examples, so this is something to consider. I realize a lot of this has it's root in the application, e.g. shift-registers (index 0 means it's run through 0 shift registers). But it's been adopted for the mathematics because it's useful there as well (e.g. because x^0 = 1 for any non-zero value of x). Both mathematics and programming have two kinds of iterations: where index matters, and where it doesn't (why not iterate 'apple', 'banana', 'cherry' etc.). In practically all cases I deal with where the index matters, zero-based suits me better. The one-based indexing Matlab uses drives me crazy, and that's specifically designed for engineers. Martin -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-3790 Fax: +49 721 608-6071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgp8yPohaXQUF.pgp Description: PGP signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On Aug 20, 1:23 am, Martin Braun martin.br...@kit.edu wrote: I find this thread extremely interesting, but what surprised me that everyone seems to agree that mathematics is 1-based, but we Pythoneers should stick to zero-based. I disagree. To make sure I'm not going crazy, I took the top five books lying on my desk, which were the DSP book by Oppenheim/Schafer, two books by Stephen M. Kay (Spectral Estimation and Estimation Theory) and the Channel Coding book by Lin Costello. This is isn't pure mathematics (as in proving the Goldbach conjecture), but nevertheless, this is serious mathematics and, surprise, they most exclusively use zero-based notation. You probably don't have those books in grabbing distance, so here's some examples for zero-based stuff: That's interesting, but I think zero-based indexing is rare in the literature of mathematics, applied math, science and engineering. All the literature I've ever seen that uses vectors and matrices is one- based, and that includes text books and technical papers. It all boils down to personal preference, but I just find it strange that we would not try to make programming as consistent as possible with notational conventions in the literature. If I try to implement some algorithm I find in a technical book or paper, why should I have to mentally offset every index by one? That's very error prone, and I have more important things to think about. Then again, I don't do that very often, so maybe it's not a big deal. The zero-based indexing just seemed wrong to me when I first saw it. I'm used to it by now, but it still doesn't seem quite right to me. It's almost right -- but it's off by one. I still have a habit of taking the 1 element when I really want the 0 element. Most programmers probably never use vectors and matrices, so they don't care about the inconsistency with standard mathematical notation. And yes, I understand that zero-based indexing can be slightly more efficient. That's why I think it's appropriate for low-level languages such as C. However, I think one-based indexing is more appropriate for high-level languages. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On Fri, Aug 20, 2010 at 11:01 AM, Russ P. russ.paie...@gmail.com wrote: On Aug 20, 1:23 am, Martin Braun martin.br...@kit.edu wrote: I find this thread extremely interesting, but what surprised me that everyone seems to agree that mathematics is 1-based, but we Pythoneers should stick to zero-based. I disagree. To make sure I'm not going crazy, I took the top five books lying on my desk, which were the DSP book by Oppenheim/Schafer, two books by Stephen M. Kay (Spectral Estimation and Estimation Theory) and the Channel Coding book by Lin Costello. This is isn't pure mathematics (as in proving the Goldbach conjecture), but nevertheless, this is serious mathematics and, surprise, they most exclusively use zero-based notation. You probably don't have those books in grabbing distance, so here's some examples for zero-based stuff: That's interesting, but I think zero-based indexing is rare in the literature of mathematics, applied math, science and engineering. All the literature I've ever seen that uses vectors and matrices is one- based, and that includes text books and technical papers. Not sure what you read, but for me (mostly number theory, numerical analysis, and abstract algebra) zero-based indexing is quite common. It all boils down to personal preference, but I just find it strange that we would not try to make programming as consistent as possible with notational conventions in the literature. If I try to implement some algorithm I find in a technical book or paper, why should I have to mentally offset every index by one? That's very error prone, and I have more important things to think about. Then again, I don't do that very often, so maybe it's not a big deal. Ever read code by a mathematician? It's usually (obviously not always) a nightmare. I'm glad we break with convention, particularly when that convention is things like one-letter variables and 'reuse' of notation. Geremy Condra -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On Aug 20, 11:19 am, geremy condra debat...@gmail.com wrote: Not sure what you read, but for me (mostly number theory, numerical analysis, and abstract algebra) zero-based indexing is quite common. My background is in aerospace control engineering. I am certainly not familiar with the literature in pure mathematics, but I assume that the math textbooks I used on college used standard mathematical notation. If one-based indexing is becoming more common in the literature, I'll bet that is only because it is so widely used in computer programming -- not because the writers decided independently that it is a better notation. But that's just a guess on my part. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On Fri, Aug 20, 2010 at 12:31 PM, Russ P. russ.paie...@gmail.com wrote: On Aug 20, 11:19 am, geremy condra debat...@gmail.com wrote: Not sure what you read, but for me (mostly number theory, numerical analysis, and abstract algebra) zero-based indexing is quite common. My background is in aerospace control engineering. I am certainly not familiar with the literature in pure mathematics, but I assume that the math textbooks I used on college used standard mathematical notation. If one-based indexing is becoming more common in the literature, I'll bet that is only because it is so widely used in computer programming -- not because the writers decided independently that it is a better notation. But that's just a guess on my part. I can't speak for the motivation for selecting that notation, but I'm not sure it matters anyway- if the rationale for a switch is to become consistent with mathematical notation and the 0-based indexing is becoming a common notation in that field then we achieve consistency by standing still. Geremy Condra -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
Lawrence D'Oliveiro wrote: That is not some kind of ordinal numbering of the terms, that is the power of the variable involved. It's both. Convention is to make the power and the index of the coefficent the same, because it would be pointlessly confusing to do anything else. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
Martin Gregorie wrote:
On Mon, 16 Aug 2010 12:33:51 +1200, Gregory Ewing wrote:
Ian Kelly wrote:
On Fri, Aug 13, 2010 at 11:53 AM, Martin Gregorie
mar...@address-in-sig.invalid wrote:
real sample[-500:750];
Ugh, no. The ability to change the minimum index is evil.
Not always; it can have its uses, particularly when you're using the
array as a mapping rather than a collection.
Say you have intensity data captured from an X-ray goniometer from 160
degrees to 30 degrees at 0.01 degree resolution. Which is most evil of
the following?
1) real intensity[16000:3000]
for i from lwb intensity to upb intensity
plot(i/100, intensity[i]);
2) double angle[13000];
double intensity[13000];
for (int i = 0; i 13000; i++)
plot(angle[i], intensity[i]);
3) struct
{
double angle;
double intensity
} measurement;
measurement m[13000];
for (int i = 0; i 13000; i++)
plot(m[i].angle, m[i].intensity);
4) double intensity[13000];
for (int i = 0; i 13000; i++)
plot((16000 - i)/100, intensity[i])
To my mind (1) is much clearer to read and far less error-prone to write,
while zero-based indexing forces you to use code like (2), (3) or (4),
all of which obscure rather than clarify what the program is doing.
This might be true if the only thing you ever do with your
indices is use them to iterate over the array. However, if
you need to do any arithmetic with them, you may find yourself
thinking again.
Also, in Python you wouldn't write iteration loops that way
in the first place. You would write things such as
for x, y in zip(angle, intensity):
plot(x, y)
which avoids dealing with indexes altogether. The only time
you really need to use indexes in Python is when you want to
do arithmetic with them, or take slices, both of which turn
out to be less confusing most of the time with 0-based indexing.
--
Greg
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
Robert Kern wrote: On 8/16/10 9:29 PM, Roy Smith wrote: In articlei4cqg0$ol...@lust.ihug.co.nz, Lawrence D'Oliveirol...@geek-central.gen.new_zealand wrote: In messageroy-ee1b7f.21001716082...@news.panix.com, Roy Smith wrote: 5) real intensity[160.0 : 30.0 : 0.01] How many elements in that array? c) neither of the above. More specifically, 13,001 (if I counted correctly). 13000, actually. Floating point is a bitch. Or 12999.999 if you're unlucky. Floating point is a *real* bitch! -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
J.B. Brown wrote: Then users of my class (mainly my research lab coworkers) could specify whichever behavior they wanted. In terms of providing readable code and removing beginning programmer confusion, But having some arrays indexed from 0 and others from 1 can be a recipe for confusion in its own right. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
Martin Braun wrote: Another thing worth mentioning (I guess here is a good a place as any other) is the fact that programming and mathematics are still pretty different things, despite how much we programmers would like to think ourselves as some kind of mathematician. Although when it comes to indexing, mathematics and programming have remarkably similar issues. I've seen mathematics texts that made a poor choice of index base and ended up with formulas confusingly littered with plus and minus ones, or where I've had to scratch my head a few times and look back to find out whether a particular index was meant to start from 0 or 1. Also it doesn't help that the sigma notation lends itself more to closed than half-open intervals, which can lead to a Hobson's choice between i-1 in the formulas and n-1 in the summation range. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
Russ P. wrote: It all boils down to personal preference, but I just find it strange that we would not try to make programming as consistent as possible with notational conventions in the literature. It doesn't matter how much mathematical convention you quote, your assertion that 1-based indexing is better won't convince me, because it flies in the face of my own personal experience. The zero-based indexing just seemed wrong to me when I first saw it. I'm used to it by now, but it still doesn't seem quite right to me. It's almost right -- but it's off by one. I still have a habit of taking the 1 element when I really want the 0 element. That may be because you haven't fully adopted 0-based indexing into your thinking. You're trying to think in terms of 1-based indexes and convert to 0-based when you code. If you think in 0-based indexes in the first place, many things become simpler. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On Wed, 18 Aug 2010 21:55:30 -0700, Russ P. wrote: On Aug 18, 7:58 pm, Steven D'Aprano steve-REMOVE- t...@cybersource.com.au wrote: On Wed, 18 Aug 2010 14:47:08 -0700, Russ P. wrote: Is the top team in the league the number 1 team -- or the number 0 team? I have yet to hear anyone call the best team the number 0 team! Why is the top team the one with the lowest number? How could it be otherwise? What is the highest number? If there are N teams, then the highest number is obviously N (if counting from 1) or N-1 (if from 0). In other words... why do we rank sporting teams Best to Worst rather than the other way around? [...] Maybe goofy was too derogatory, but I think you are rationalizing a bad decision, at least for high-level languages. I don't think programming languages should always mimic human languages, but this is one case where there is no advantage to doing otherwise. Why do you think off by one errors are so common? Because the darn indexing convention is off by one! But you have that exactly backwards. Counting from 0 leads to fewer off by one errors for many tasks. (Of course, avoiding indexing in favour of iteration leads to even fewer off by one errors.) Anyway, in a feeble attempt to move this discussion somewhere -- anywhere! -- else: http://c2.com/cgi/wiki?FencePostError http://c2.com/cgi/wiki?WhyNumberingShouldStartAtZero http://c2.com/cgi/wiki?WhyNumberingShouldStartAtOne http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/zero and of course: http://xkcd.com/163/ -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On 2010-08-19, Russ P. russ.paie...@gmail.com wrote: And I'd still like to know if the 1st element of aList is aList[0] or aList[1]. aList[0] -- Grant Edwards grant.b.edwardsYow! I'm definitely not at in Omaha! gmail.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
2010/8/9 MRAB pyt...@mrabarnett.plus.com:
Default User wrote:
Not to prolong a good food fight, but IIRC, many years ago in QBasic,
one could choose
OPTION BASE 0
or
OPTION BASE 1
When I wrote my own C++ 2-D matrix class, I wrote a member function
which did exactly this - allow you to specify the initial index value.
Then users of my class (mainly my research lab coworkers) could
specify whichever behavior they wanted.
In terms of providing readable code and removing beginning programmer
confusion, why not extend python lists by using something similar to
(but not necessarily identical to) the C++ STL containers:
C++
int myX[ ] = { 1,2,3,4,5 };
std::vectorint vectorX( myX, myX[ sizeof( myX ) - 1 ] );
std::cout vectorX.begin() std::endl;
std::cout vectorX.end() std::endl;
Python
x = [ 1 , 2 , 3 , 4 , 5 ]
print x.first()
print x.last(),
where the first and last behavior of python is to return a deep copy
of the object, and not a pointer.
It seems that this would avoid complaints about the 0/1 issue.
Of course, the problem is the behavior of:
myList = [ myObject1, myObject2, myObject3, ... , myObjectLast ]
print myList.first() + 5 ,
in which one will conceptually might want to get the 6th item in a
list, though if first() is defined to return the object, then we get
the returned object plus 5, if such behavior is defined to exist.
I completely acknowledge that the behavior is not well defined, and
that is why I am not proposing this as a final implementation, but
rather as a concept and motivation.
For those who don't like Python's 0-based indexing, why not just build
a wrapper type which features an item() method that handles the
internal conversion from 1 to 0 as the starting index?
Better yet, include a method which sets/specifies the 0/1 behavior,
and have item() reference the 0/1 setting to obtain the proper offset.
Just a thought.
J.B. Brown
Kyoto University
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On 2010-08-19, J.B. Brown jbbr...@sunflower.kuicr.kyoto-u.ac.jp wrote: When I wrote my own C++ 2-D matrix class, I wrote a member function which did exactly this - allow you to specify the initial index value. Then users of my class (mainly my research lab coworkers) could specify whichever behavior they wanted. I did something similar in a library that needs to read positions from the specification for a fixed-length fields plain text database. The printed specs for these document types often start counting character positions at 1, but not universally. For those who don't like Python's 0-based indexing, why not just build a wrapper type which features an item() method that handles the internal conversion from 1 to 0 as the starting index? Better yet, include a method which sets/specifies the 0/1 behavior, and have item() reference the 0/1 setting to obtain the proper offset. Because they know deep down they wouldn't win anything. -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On Aug 19, 9:07 am, J.B. Brown jbbr...@sunflower.kuicr.kyoto-
u.ac.jp wrote:
2010/8/9 MRAB pyt...@mrabarnett.plus.com:
Default User wrote:
Not to prolong a good food fight, but IIRC, many years ago in QBasic,
one could choose
OPTION BASE 0
or
OPTION BASE 1
When I wrote my own C++ 2-D matrix class, I wrote a member function
which did exactly this - allow you to specify the initial index value.
Then users of my class (mainly my research lab coworkers) could
specify whichever behavior they wanted.
In terms of providing readable code and removing beginning programmer
confusion, why not extend python lists by using something similar to
(but not necessarily identical to) the C++ STL containers:
C++
int myX[ ] = { 1,2,3,4,5 };
std::vectorint vectorX( myX, myX[ sizeof( myX ) - 1 ] );
std::cout vectorX.begin() std::endl;
std::cout vectorX.end() std::endl;
Python
x = [ 1 , 2 , 3 , 4 , 5 ]
print x.first()
print x.last() ,
Many years ago I wrote a fairly comprehensive vector/matrix class in C+
+. (It was an exercise to learn the intricacies of C++, and I also
really needed it.) I used a system of offset pointers to realize
indexing that starts with 1.
Years later, after I had quit using it, I decided that I should have
just bit the bullet and let the indexing start with zero for
simplicity. I believe that zero-based indexing is a mistake, but
attempts to fix it require additional boilerplate that is prone to
error and inefficiency. Short of a major language overhaul, we are
essentially stuck with zero-based indexing.
But that doesn't mean we should pretend that it was the right choice.
For those who insist that zero-based indexing is a good idea, why you
suppose mathematical vector/matrix notation has never used that
convention? I have studied and used linear algebra extensively, and I
have yet to see a single case of vector or matrix notation with zero-
based indexing in a textbook or a technical paper. Also, mathematical
summation is traditionally shown as 1 to N, not 0 to N-1. Are
mathematicians just too simple-minded and unsophisticated to
understand the value of zero-based indexing? Or have you perhaps been
mislead?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On Tue, 17 Aug 2010 19:15:54 -0700, Russ P. wrote: The convention of starting with zero may have had some slight performance advantage in the early days of computing, but the huge potential for error that it introduced made it a poor choice in the long run, at least for high-level languages. People keep saying this, but it's actually the opposite. Signpost errors and off-by-one errors are more common in languages that count from one. A simple example: Using zero-based indexing, suppose you want to indent the string spam so it starts at column 4. How many spaces to you prepend? 0123456789 spam Answer: 4. Nice and easy and almost impossible to get wrong. To indent to position n, prepend n spaces. Now consider one-based indexing, where the string starts at column 5: 1234567890 spam Answer: 5-1 = 4. People are remarkably bad at remembering to subtract the 1, hence the off-by-one errors. Zero-based counting doesn't entirely eliminate off-by-one errors, but the combination of that plus half-open on the right intervals reduces them as much as possible. The intuitive one-based closed interval notation used in many natural languages is terrible for encouraging off-by-one errors. Quick: how many days are there between Friday 20th September and Friday 27th September inclusive? If you said seven, you fail. One-based counting is the product of human intuition. Zero-based counting is the product of human reason. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On Aug 19, 11:04 am, Steven D'Aprano st...@remove-this- cybersource.com.au wrote: On Tue, 17 Aug 2010 19:15:54 -0700, Russ P. wrote: The convention of starting with zero may have had some slight performance advantage in the early days of computing, but the huge potential for error that it introduced made it a poor choice in the long run, at least for high-level languages. People keep saying this, but it's actually the opposite. Signpost errors and off-by-one errors are more common in languages that count from one. A simple example: Using zero-based indexing, suppose you want to indent the string spam so it starts at column 4. How many spaces to you prepend? 0123456789 spam Answer: 4. Nice and easy and almost impossible to get wrong. To indent to position n, prepend n spaces. Now consider one-based indexing, where the string starts at column 5: 1234567890 spam Answer: 5-1 = 4. People are remarkably bad at remembering to subtract the 1, hence the off-by-one errors. Zero-based counting doesn't entirely eliminate off-by-one errors, but the combination of that plus half-open on the right intervals reduces them as much as possible. The intuitive one-based closed interval notation used in many natural languages is terrible for encouraging off-by-one errors. Quick: how many days are there between Friday 20th September and Friday 27th September inclusive? If you said seven, you fail. The error mode you refer to is much less common than the typical off- by-one error mode. In the far more common error mode, zero-based indexing is far more error prone. One-based counting is the product of human intuition. Zero-based counting is the product of human reason. I suggest you take that up with mathematicians, who have used one- based indexing all along. That's why it was used in Fortran and Matlab, among other more mathematical and numerically oriented and languages. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
I just checked, and Mathematica uses one-based indexing. Apparently they want their notation to look mathematical. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On Thu, 19 Aug 2010 11:03:53 -0700, Russ P. wrote: For those who insist that zero-based indexing is a good idea, why you suppose mathematical vector/matrix notation has never used that convention? I have studied and used linear algebra extensively, and I have yet to see a single case of vector or matrix notation with zero- based indexing in a textbook or a technical paper. Also, mathematical summation is traditionally shown as 1 to N, not 0 to N-1. In my experience, it's more likely to be 0 to N than either of the above, thus combining the worst of both notations. Are mathematicians just too simple-minded and unsophisticated to understand the value of zero-based indexing? No, mathematicians are addicted to tradition. Unlike computer scientists, who create new languages with radically different notation and syntax at the drop of a hat, mathematicians almost never change existing notation. Sometimes they *add* new notation, but more often they just re-use old notation in a new context. E.g. if you see (5, 8), does that mean a coordinate pair, a two-tuple, an open interval, or something else? Additionally, mathematical notation isn't chosen for its ability to encourage or discourage errors. It seems often to be chosen arbitrarily, or for convenience, but mostly out of tradition and convention. Why do we use x for unknown? Why do we use i for an integer value, but not r for a real or c for a complex value? Mathematicians are awfully lazy -- laziness is one of the cardinal virtues of the mathematician, as it is of programmers -- but they value brevity and conciseness over notation that improves readability and robustness. That's why they (e.g.) they use implicit multiplication, a plethora of line noise symbols that would boggle even Perl programmers, and two-dimensional syntax where the meaning of tokens depends on where they are written relative to some other token. (E.g. subscript, superscript, and related forms.) There is one slightly mainstream language that uses mathematical notation: APL. The result isn't pretty. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On Thu, 19 Aug 2010 11:39:05 -0700, Russ P. wrote: I just checked, and Mathematica uses one-based indexing. Apparently they want their notation to look mathematical. Well duh. It's called MATHematica, not PROGematica. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On Aug 19, 11:42 am, Steven D'Aprano st...@remove-this- cybersource.com.au wrote: On Thu, 19 Aug 2010 11:03:53 -0700, Russ P. wrote: For those who insist that zero-based indexing is a good idea, why you suppose mathematical vector/matrix notation has never used that convention? I have studied and used linear algebra extensively, and I have yet to see a single case of vector or matrix notation with zero- based indexing in a textbook or a technical paper. Also, mathematical summation is traditionally shown as 1 to N, not 0 to N-1. In my experience, it's more likely to be 0 to N than either of the above, thus combining the worst of both notations. Are mathematicians just too simple-minded and unsophisticated to understand the value of zero-based indexing? No, mathematicians are addicted to tradition. That is probably true. But computer languages are addicted to more than tradition. They're addicted to compatibility and familiarity. I don't know where zero-based indexing started, but I know that C used it very early, probably for some minuscule performance advantage. When C++ came along, it tried to be somewhat compatible with C, so it continued using zero-based indexing. Then Java was loosely modeled after C++, so the convention continued. Python was written in C, so zero-based indexing was natural. So the whole thing is based on a decision by some guy who was writing a language for operating systems, not mathematics or application programming. Unlike computer scientists, who create new languages with radically different notation and syntax at the drop of a hat, mathematicians almost never change existing notation. Sometimes they *add* new notation, but more often they just re-use old notation in a new context. E.g. if you see (5, 8), does that mean a coordinate pair, a two-tuple, an open interval, or something else? Additionally, mathematical notation isn't chosen for its ability to encourage or discourage errors. It seems often to be chosen arbitrarily, or for convenience, but mostly out of tradition and convention. Why do we use x for unknown? Why do we use i for an integer value, but not r for a real or c for a complex value? Mathematicians are awfully lazy -- laziness is one of the cardinal virtues of the mathematician, as it is of programmers -- but they value brevity and conciseness over notation that improves readability and robustness. That's why they (e.g.) they use implicit multiplication, a plethora of line noise symbols that would boggle even Perl programmers, and two-dimensional syntax where the meaning of tokens depends on where they are written relative to some other token. (E.g. subscript, superscript, and related forms.) There is one slightly mainstream language that uses mathematical notation: APL. The result isn't pretty. As I wrote above, the use of zero-based indexing in C++, Java, and Python are all simply based on the fact that C used it. I wouldn't have guessed that APL is a mainstream language. As I wrote in recent posts, Fortran, Matlab, and Mathematica all used one- based indexing. Maybe Basic too, but I haven't checked. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On Thu, 19 Aug 2010 11:27:18 -0700, Russ P. wrote: [...] Zero-based counting doesn't entirely eliminate off-by-one errors, but the combination of that plus half-open on the right intervals reduces them as much as possible. The intuitive one-based closed interval notation used in many natural languages is terrible for encouraging off-by-one errors. Quick: how many days are there between Friday 20th September and Friday 27th September inclusive? If you said seven, you fail. The error mode you refer to is much less common than the typical off- by-one error mode. In the far more common error mode, zero-based indexing is far more error prone. So you say, and yet you don't give any examples of this far more common error mode. One-based counting is the product of human intuition. Zero-based counting is the product of human reason. I suggest you take that up with mathematicians, who have used one- based indexing all along. That's why it was used in Fortran and Matlab, among other more mathematical and numerically oriented and languages. Mathematics is an ancient art that values tradition and convention. It doesn't matter how hard it was to come up with a proof, or how difficult to verify it. Mathematicians value logical correctness and some undefinable sense of elegance over how easy it is to verify, the readability of the notation, resistance to errors, and the ability of mediocre mathematicians to make useful contributions. Mathematical notation and conventions are not, by any stretch of the imagination, designed to reduce errors. Mathematicians consider it a good thing that they are still mostly using the same notation invented by (say) Leibniz. Programming language design is a young art that values reliability and ease of use over tradition. While correctness of the code is important, equally important (if not more so) is readability, resistance to errors, and the ability of mediocre programmers to write code that works. Or at least code that can be hammered into working by slightly less mediocre programmers. Maintenance of code is usually more difficult than writing it in the first place, and consequently languages often are designed specifically to reduce errors rather than to use the exact same notation than Grace Hopper or Charles Babbage used. While businesses are conservative in which languages they choose, language designers are not conservative in the design features they come up with. That there has been a gradual (although as yet incomplete) convergence towards zero-based indexing in languages aimed at programmers, and one-based indexing in languages aimed at non- programmers, tells you everything you need to know. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
Yes, apparently Basic uses one-based indexing too. As for Ada, apparently, the programmer needs to explicitly define the index range for every array. Weird. But I get the impression that one- based indexing is used much more than zero-based indexing. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On 08/19/2010 02:04 PM, Steven D'Aprano wrote: On Tue, 17 Aug 2010 19:15:54 -0700, Russ P. wrote: The convention of starting with zero may have had some slight performance advantage in the early days of computing, but the huge potential for error that it introduced made it a poor choice in the long run, at least for high-level languages. People keep saying this, but it's actually the opposite. Signpost errors and off-by-one errors are more common in languages that count from one. A simple example: Using zero-based indexing, suppose you want to indent the string spam so it starts at column 4. How many spaces to you prepend? 0123456789 spam Doesn't it start at column 5 as shown? Anyway, it's far more common, I think, to iterate over a sequence and say my list is 12 items long. I need to check if I'm on 12th item and do something special. Doh, I mean, 11th item. In my view, this is far, far more common, especially for people new to programming, and isn't one of Python mottos programming for everybody? In other words, starting with 0 leads to implicit error every time you simply pause and think at which item am I now and how many items have I got so far? which are the two most basic questions involved in iteration. I'm not saying that 1-th indexing is necessarily better in programming than 0-th indexing, all things considered. It's an arguable question, it depends on what kind of operations are more common, and I can't know this for everyone. I am saying that it is much more natural for people new to programming and outside of programming to count from 1, and I imagine the reason for this is simply that it's most useful in vast majority of real usage people deal with. It's just annoying that people bring up, for example, ground floor/ first floor as proof that both are equally natural. (I don't mean you, I know you said you agree that 1-th indexing is more intuitive). -ak -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On Aug 19, 12:13 pm, Steven D'Aprano st...@remove- While businesses are conservative in which languages they choose, language designers are not conservative in the design features they come up with. That there has been a gradual (although as yet incomplete) convergence towards zero-based indexing in languages aimed at programmers, and one-based indexing in languages aimed at non- programmers, tells you everything you need to know. I beg to differ. I remember reading Bjarne Stroustrup's rationale for adopting all sorts of junk from C that he really didn't want, just to make C++ reasonably compatible with it. Had he not done that, C++ probably would have died on the vine. I'm sure the same was true of Java and Python too. In any case, I need to drop this discussion and move on. Mr. D'Aprano, I usually find your posts enlightening and amusing, but in this case just don't seem to be converging. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On Thu, 19 Aug 2010 11:57:53 -0700, Russ P. wrote: I don't know where zero-based indexing started, but I know that C used it very early, probably for some minuscule performance advantage. In C, zero based indexing was used because it made pointer arithmetic elegant and reduced bugs. When C++ came along, it tried to be somewhat compatible with C, so it continued using zero-based indexing. And because a feature that isn't broken doesn't need to be fixed. Then Java was loosely modeled after C++, so the convention continued. Python was written in C, so zero-based indexing was natural. So the whole thing is based on a decision by some guy who was writing a language for operating systems, not mathematics or application programming. Python is vastly different from C. It has just as many similarities to Pascal as C, which uses 1-based indexing. No surprise there -- Python, like both Pascal and C, is a member of the Algol family of languages. It is interesting to see that Nicholas Wirth's first language, Pascal, used one-based indexing, and his latest, Oberon, uses zero-based. Say what you like about Wirth, but he's not influenced by the desire to be like C. Oberon uses the same zero-based half-open on the right indexing as Python: VAR a: ARRAY 10 OF INTEGER; creates an array a[0]...a[9]. If Wirth has moved to the Python convention, it is because it *works*, not because he's trying to ape C. Not all languages are based on Algol. Languages derived from Lisp also start array indexing at 0. So does Forth. So that's at least three significantly different language families which have independently converged on zero-based indexing. [...] I wouldn't have guessed that APL is a mainstream language. I said slightly. It was surprisingly popular in it's time, and there are still multiple APL compilers and interpreters for Windows, Linux and Mac. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
Russ P. wrote: On Aug 19, 11:42 am, Steven D'Aprano st...@remove-this- cybersource.com.au wrote: On Thu, 19 Aug 2010 11:03:53 -0700, Russ P. wrote: For those who insist that zero-based indexing is a good idea, why you suppose mathematical vector/matrix notation has never used that convention? I have studied and used linear algebra extensively, and I have yet to see a single case of vector or matrix notation with zero- based indexing in a textbook or a technical paper. Also, mathematical summation is traditionally shown as 1 to N, not 0 to N-1. In my experience, it's more likely to be 0 to N than either of the above, thus combining the worst of both notations. Are mathematicians just too simple-minded and unsophisticated to understand the value of zero-based indexing? No, mathematicians are addicted to tradition. That is probably true. But computer languages are addicted to more than tradition. They're addicted to compatibility and familiarity. I don't know where zero-based indexing started, but I know that C used it very early, probably for some minuscule performance advantage. When C++ came along, it tried to be somewhat compatible with C, so it continued using zero-based indexing. Then Java was loosely modeled after C++, so the convention continued. Python was written in C, so zero-based indexing was natural. So the whole thing is based on a decision by some guy who was writing a language for operating systems, not mathematics or application programming. [snip] C was derived ultimately from BCPL. In C array indexing is syntactic sugar for pointer arithmetic with dereferencing, so: p[i] means the same as: *(p + i) BCPL, IIRC, didn't use the familiar indexing syntax. !p was the equivalent of *p and p!i was short for !(p + i), the equivalent of p[i]. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
Russ P. wrote: Yes, apparently Basic uses one-based indexing too. For arrays, yes and no. Traditionally, DIM A(10) has 11 elements, starting at 0, although it might depend on the version of Basic. For strings, yes. As for Ada, apparently, the programmer needs to explicitly define the index range for every array. Weird. But I get the impression that one- based indexing is used much more than zero-based indexing. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On Thu, Aug 19, 2010 at 12:32 PM, Steven D'Aprano st...@remove-this-cybersource.com.au wrote: On Thu, 19 Aug 2010 11:57:53 -0700, Russ P. wrote: I don't know where zero-based indexing started, but I know that C used it very early, probably for some minuscule performance advantage. In C, zero based indexing was used because it made pointer arithmetic elegant and reduced bugs. That's because in C, an array 'index' is not an ordinal, but a distance. Distances are easier to work with if you are comparing indices and performing arithmetic on them, while ordinals are easier to work with for straightforward I'd-like-this-element-please. I'm personally glad that Python uses the former. Geremy Condra -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On 08/17/2010 10:15 PM, Russ P. wrote: On Aug 7, 5:54 am, D'Arcy J.M. Cainda...@druid.net wrote: Would said beginner also be surprised that a newborn baby is zero years old or would it be more natural to call them a one year old? Zero based counting is perfectly natural. You're confusing continuous and discrete variables. Time is a continuous variable, but a list index is discrete. Take a look at any numbered list, such as the top ten football teams or the top ten software companies. Have you ever seen such a list start with zero? If so, where? I sure haven't. When I studied linear algebra way back, vector and matrix indices also always started with one, and I assume they still do. The convention of starting with zero may have had some slight performance advantage in the early days of computing, but the huge potential for error that it introduced made it a poor choice in the long run, at least for high-level languages. I have to agree, there's innumerable number of examples where sequential number of an item in a series is counted starting with one. Second loaf of bread; third day of vacation, first cup of tea today, first gray hair, 50th anniversary, 2nd century AD, and approximately a gazillion other examples. Contrast this with _one_ example that was repeated in this thread of there being ground floor, 1st floor, 2nd, and so on. However! Consider that ground floor is kind of different from the other floors. It's the floor that's not built up over ground, but is already there -- in case of the most primitive dwelling, you can put some sawdust over the ground, put a few boards overhead and it's a home, although probably not a house. But does it really have what can be officially called a floor? On a more practical angle, ground floors usually have the lobby, receptionists, storefronts and stores, etc; while 1st floor and up are business/residential. I think different numbering from pretty much all other things out there gives you a hint that the ground floor is a different animal. -andrei -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On 08/17/2010 10:15 PM, Russ P. wrote: On Aug 7, 5:54 am, D'Arcy J.M. Cainda...@druid.net wrote: Would said beginner also be surprised that a newborn baby is zero years old or would it be more natural to call them a one year old? Zero based counting is perfectly natural. You're confusing continuous and discrete variables. Time is a continuous variable, but a list index is discrete. Take a look at any numbered list, such as the top ten football teams or the top ten software companies. Have you ever seen such a list start with zero? If so, where? I sure haven't. When I studied linear algebra way back, vector and matrix indices also always started with one, and I assume they still do. The convention of starting with zero may have had some slight performance advantage in the early days of computing, but the huge potential for error that it introduced made it a poor choice in the long run, at least for high-level languages. Besides that, the way things are now, it's almost an Abbot Costello routine: - How many folders are there? - 5 - Ok, give me the fourth one. - Here. - No, that's the last one! - That's what you said! - No, I said, fourth one! - That's what I did! - How many are there in all? - I already said, five! - You gave me the last one!! - Just like you said - fourth -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On Aug 18, 2:01 pm, AK andrei@gmail.com wrote: On 08/17/2010 10:15 PM, Russ P. wrote: On Aug 7, 5:54 am, D'Arcy J.M. Cainda...@druid.net wrote: Would said beginner also be surprised that a newborn baby is zero years old or would it be more natural to call them a one year old? Zero based counting is perfectly natural. You're confusing continuous and discrete variables. Time is a continuous variable, but a list index is discrete. Take a look at any numbered list, such as the top ten football teams or the top ten software companies. Have you ever seen such a list start with zero? If so, where? I sure haven't. When I studied linear algebra way back, vector and matrix indices also always started with one, and I assume they still do. The convention of starting with zero may have had some slight performance advantage in the early days of computing, but the huge potential for error that it introduced made it a poor choice in the long run, at least for high-level languages. Besides that, the way things are now, it's almost an Abbot Costello routine: - How many folders are there? - 5 - Ok, give me the fourth one. - Here. - No, that's the last one! - That's what you said! - No, I said, fourth one! - That's what I did! - How many are there in all? - I already said, five! - You gave me the last one!! - Just like you said - fourth Yes, it's confusing. Which element of a list is the first element? Wait, first is sometimes abbreviated as 1st. So is the 1st element the 0 element or the 1 element? I honestly don't know. Is the top team in the league the number 1 team -- or the number 0 team? I have yet to hear anyone call the best team the number 0 team! Unfortunately, we're stuck with this goofy numbering system in many languages. Fortunately, the trend is away from explicit indexing and toward for loops when possible. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On 18/08/2010 22:47, Russ P. wrote: On Aug 18, 2:01 pm, AKandrei@gmail.com wrote: On 08/17/2010 10:15 PM, Russ P. wrote: On Aug 7, 5:54 am, D'Arcy J.M. Cainda...@druid.netwrote: Would said beginner also be surprised that a newborn baby is zero years old or would it be more natural to call them a one year old? Zero based counting is perfectly natural. You're confusing continuous and discrete variables. Time is a continuous variable, but a list index is discrete. Take a look at any numbered list, such as the top ten football teams or the top ten software companies. Have you ever seen such a list start with zero? If so, where? I sure haven't. When I studied linear algebra way back, vector and matrix indices also always started with one, and I assume they still do. The convention of starting with zero may have had some slight performance advantage in the early days of computing, but the huge potential for error that it introduced made it a poor choice in the long run, at least for high-level languages. Besides that, the way things are now, it's almost an Abbot Costello routine: - How many folders are there? - 5 - Ok, give me the fourth one. - Here. - No, that's the last one! - That's what you said! - No, I said, fourth one! - That's what I did! - How many are there in all? - I already said, five! - You gave me the last one!! - Just like you said - fourth Yes, it's confusing. Which element of a list is the first element? Wait, first is sometimes abbreviated as 1st. So is the 1st element the 0 element or the 1 element? I honestly don't know. Is the top team in the league the number 1 team -- or the number 0 team? I have yet to hear anyone call the best team the number 0 team! Unfortunately, we're stuck with this goofy numbering system in many languages. Fortunately, the trend is away from explicit indexing and toward for loops when possible. Bring back Coral 66, all is forgiven. http://www.xgc.com/manuals/xgc-c66-rm/x357.html Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On Wed, 18 Aug 2010 16:56:22 -0400, AK wrote: Contrast this with _one_ example that was repeated in this thread of there being ground floor, 1st floor, 2nd, and so on. However! Consider that ground floor is kind of different from the other floors. It's the floor that's not built up over ground, but is already there -- in case of the most primitive dwelling, you can put some sawdust over the ground, put a few boards overhead and it's a home, although probably not a house. But does it really have what can be officially called a floor? That's the perfect example, although perhaps for an [apparently] unintended reason g: I think that the notion of a qualitatively different ground floor is European, or at least that's the way I remember it from my high school French class way back in the late 1970s. In the U.S., when you walk into a building (even a very tall commercial building), that's the first floor, and when you go up a level, that's the second floor, and all the room/suite/office numbers are two hundred and something. I also seem to recall that some European buildings have a mezzanine floor between the ground floor and the floor whose reference number is 1, but again, high school was a long time ago. Dan -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On Wed, 18 Aug 2010 14:47:08 -0700, Russ P. wrote: Is the top team in the league the number 1 team -- or the number 0 team? I have yet to hear anyone call the best team the number 0 team! Why is the top team the one with the lowest number? Unfortunately, we're stuck with this goofy numbering system in many languages. Fortunately, the trend is away from explicit indexing and toward for loops when possible. Agreed on the second sentence there, but not on the first. There's nothing goofy about indexing items from 0. Yes, it does lead to slight more difficulty when discussing which item you want in *human* languages, but not in *programming* languages. The nth item is always the nth item. The only difference is whether n starts at 0 or 1, and frankly, if you (generic you, not you personally) can't learn which to use, you have no business pretending to be a programmer. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On Aug 18, 7:58 pm, Steven D'Aprano steve-REMOVE- t...@cybersource.com.au wrote: On Wed, 18 Aug 2010 14:47:08 -0700, Russ P. wrote: Is the top team in the league the number 1 team -- or the number 0 team? I have yet to hear anyone call the best team the number 0 team! Why is the top team the one with the lowest number? How could it be otherwise? What is the highest number? Here's a couple of things I'd like to see just once before I die: 1. The winner of the championship game chanting, We're number zero! We're number zero! 2. The loser of the championship game chanting, We're number one! We're number one! Unfortunately, we're stuck with this goofy numbering system in many languages. Fortunately, the trend is away from explicit indexing and toward for loops when possible. Agreed on the second sentence there, but not on the first. There's nothing goofy about indexing items from 0. Yes, it does lead to slight more difficulty when discussing which item you want in *human* languages, but not in *programming* languages. The nth item is always the nth item. The only difference is whether n starts at 0 or 1, and frankly, if you (generic you, not you personally) can't learn which to use, you have no business pretending to be a programmer. Maybe goofy was too derogatory, but I think you are rationalizing a bad decision, at least for high-level languages. I don't think programming languages should always mimic human languages, but this is one case where there is no advantage to doing otherwise. Why do you think off by one errors are so common? Because the darn indexing convention is off by one! And I'd still like to know if the 1st element of aList is aList[0] or aList[1]. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On 08/16/10 21:54, David Cournapeau wrote: On Mon, Aug 16, 2010 at 9:53 AM, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: On Aug 7, 2010, at 9:14 PM, John Nagle wrote: The languages which have real multidimensional arrays, rather than arrays of arrays, tend to use 1-based subscripts. That reflects standard practice in mathematics. Not always -- mathematicians use whatever starting index is most convenient for the problem at hand. Yes, there are many engineering fields where index starts at 0. Partly for the reason you have stated concerning polynomials, especially since this extend to series, which are pervasive in numerical computing. In linear algebra, though, I remember to have always noted matrices indexes in the [1,n] range, not [0,n-1]. I'm sure some would prefer to denote it as [0, n) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On 8/16/10 11:10 PM, Steven D'Aprano wrote: On Mon, 16 Aug 2010 22:56:20 -0500, Robert Kern wrote: On 8/16/10 9:29 PM, Roy Smith wrote: In articlei4cqg0$ol...@lust.ihug.co.nz, Lawrence D'Oliveirol...@geek-central.gen.new_zealand wrote: In messageroy-ee1b7f.21001716082...@news.panix.com, Roy Smith wrote: 5) real intensity[160.0 : 30.0 : 0.01] How many elements in that array? a) 2999 b) 3000 c) neither of the above c) neither of the above. More specifically, 13,001 (if I counted correctly). 13000, actually. Floating point is a bitch. [~/Movies] |1 import numpy [~/Movies] |2 len(numpy.r_[160.0:30.0:-0.01]) 13000 Actually, the answer is 0, not 13000, because the step size is given as 0.01, not -0.01. import numpy len(numpy.r_[160.0:30.0:-0.01]) 13000 len(numpy.r_[160.0:30.0:0.01]) 0 Roy wasn't using numpy/Python semantics but made-up semantics (following Martin Gregorie's made-up semantics to which he was replying) which treat the step size as a true size, not a size and direction. The direction is determined from the start and stop parameters. It's an almost-reasonable design. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On Tue, 17 Aug 2010 10:22:27 -0500, Robert Kern wrote: On 8/16/10 11:10 PM, Steven D'Aprano wrote: On Mon, 16 Aug 2010 22:56:20 -0500, Robert Kern wrote: On 8/16/10 9:29 PM, Roy Smith wrote: In articlei4cqg0$ol...@lust.ihug.co.nz, Lawrence D'Oliveirol...@geek-central.gen.new_zealand wrote: In messageroy-ee1b7f.21001716082...@news.panix.com, Roy Smith wrote: 5) real intensity[160.0 : 30.0 : 0.01] How many elements in that array? a) 2999 b) 3000 c) neither of the above c) neither of the above. More specifically, 13,001 (if I counted correctly). 13000, actually. Floating point is a bitch. [~/Movies] |1 import numpy [~/Movies] |2 len(numpy.r_[160.0:30.0:-0.01]) 13000 Actually, the answer is 0, not 13000, because the step size is given as 0.01, not -0.01. import numpy len(numpy.r_[160.0:30.0:-0.01]) 13000 len(numpy.r_[160.0:30.0:0.01]) 0 Roy wasn't using numpy/Python semantics but made-up semantics (following Martin Gregorie's made-up semantics to which he was replying) which treat the step size as a true size, not a size and direction. The direction is determined from the start and stop parameters. It's an almost-reasonable design. That wasn't a made-up example: AFAICR and ignoring a missing semi-colon it was an Algol 68 snippet. The semantics of the for statement and the use of lwb and upb operators to extract the bounds from a 1-dimensional array are correct A68, but OTOH its a very long time since I last programmed in that language. I used that rather than Python because Algol 68 supports the non-zero lower bound and treats the array limits as attributes of the array. -- martin@ | Martin Gregorie gregorie. | Essex, UK org | -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
In article i4ehad$k6...@localhost.localdomain, Martin Gregorie mar...@address-in-sig.invalid wrote: Roy wasn't using numpy/Python semantics but made-up semantics (following Martin Gregorie's made-up semantics to which he was replying) which treat the step size as a true size, not a size and direction. The direction is determined from the start and stop parameters. It's an almost-reasonable design. That wasn't a made-up example: AFAICR and ignoring a missing semi-colon it was an Algol 68 snippet. It was a made up example. Any similarity to a real programming language, living or dead, was purely a coincidence. I suspect I've probably also written a viable code snippet in Whitespace as well (http://compsoc.dur.ac.uk/whitespace/). That, too, is a coincidence. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
In article 4c6a8cf...@dnews.tpgi.com.au, Lie Ryan lie.1...@gmail.com wrote: On 08/16/10 21:54, David Cournapeau wrote: On Mon, Aug 16, 2010 at 9:53 AM, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: On Aug 7, 2010, at 9:14 PM, John Nagle wrote: The languages which have real multidimensional arrays, rather than arrays of arrays, tend to use 1-based subscripts. That reflects standard practice in mathematics. Not always -- mathematicians use whatever starting index is most convenient for the problem at hand. Yes, there are many engineering fields where index starts at 0. Partly for the reason you have stated concerning polynomials, especially since this extend to series, which are pervasive in numerical computing. In linear algebra, though, I remember to have always noted matrices indexes in the [1,n] range, not [0,n-1]. I'm sure some would prefer to denote it as [0, n) Only if there's an emacs mode which can do the parenthesis matching correctly ;-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On Tue, Aug 17, 2010 at 7:59 AM, Lie Ryan lie.1...@gmail.com wrote: On 08/16/10 21:54, David Cournapeau wrote: On Mon, Aug 16, 2010 at 9:53 AM, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: On Aug 7, 2010, at 9:14 PM, John Nagle wrote: The languages which have real multidimensional arrays, rather than arrays of arrays, tend to use 1-based subscripts. That reflects standard practice in mathematics. Not always -- mathematicians use whatever starting index is most convenient for the problem at hand. Yes, there are many engineering fields where index starts at 0. Partly for the reason you have stated concerning polynomials, especially since this extend to series, which are pervasive in numerical computing. In linear algebra, though, I remember to have always noted matrices indexes in the [1,n] range, not [0,n-1]. I'm sure some would prefer to denote it as [0, n) Count me in on that, that'd be great. Geremy Condra -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On Aug 7, 5:54 am, D'Arcy J.M. Cain da...@druid.net wrote: Would said beginner also be surprised that a newborn baby is zero years old or would it be more natural to call them a one year old? Zero based counting is perfectly natural. You're confusing continuous and discrete variables. Time is a continuous variable, but a list index is discrete. Take a look at any numbered list, such as the top ten football teams or the top ten software companies. Have you ever seen such a list start with zero? If so, where? I sure haven't. When I studied linear algebra way back, vector and matrix indices also always started with one, and I assume they still do. The convention of starting with zero may have had some slight performance advantage in the early days of computing, but the huge potential for error that it introduced made it a poor choice in the long run, at least for high-level languages. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
in 639663 20100815 120123 Lawrence D'Oliveiro l...@geek-central.gen.new_zealand wrote: In message mailman.2084.1281741048.1673.python-l...@python.org, Ian Kelly wrote: The ability to change the minimum index is evil. Pascal allowed you to do that. And nobody ever characterized Pascal as âevilâ. Not for that reason, anyway... Why do you refer to Pascal in the past tense? I use it most days (Delphi Free Pascal). -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On Mon, 16 Aug 2010 16:28:46 +1200, Lawrence D'Oliveiro wrote: In message 8crg0effb...@mid.individual.net, Gregory Ewing wrote: For example, the constant term of a polynomial is usually called term 0, not term 1. That is not some kind of ordinal numbering of the terms, that is the power of the variable involved. And polynomials can have negative powers, too. Not so. Polynomials, by definition, are limited to non-negative integer powers. You're thinking of a polynomial quotient, otherwise known as a rational function. http://mathworld.wolfram.com/Polynomial.html -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On Mon, 16 Aug 2010 12:33:51 +1200, Gregory Ewing wrote:
Ian Kelly wrote:
On Fri, Aug 13, 2010 at 11:53 AM, Martin Gregorie
mar...@address-in-sig.invalid wrote:
real sample[-500:750];
Ugh, no. The ability to change the minimum index is evil.
Not always; it can have its uses, particularly when you're using the
array as a mapping rather than a collection.
Say you have intensity data captured from an X-ray goniometer from 160
degrees to 30 degrees at 0.01 degree resolution. Which is most evil of
the following?
1) real intensity[16000:3000]
for i from lwb intensity to upb intensity
plot(i/100, intensity[i]);
2) double angle[13000];
double intensity[13000];
for (int i = 0; i 13000; i++)
plot(angle[i], intensity[i]);
3) struct
{
double angle;
double intensity
} measurement;
measurement m[13000];
for (int i = 0; i 13000; i++)
plot(m[i].angle, m[i].intensity);
4) double intensity[13000];
for (int i = 0; i 13000; i++)
plot((16000 - i)/100, intensity[i])
To my mind (1) is much clearer to read and far less error-prone to write,
while zero-based indexing forces you to use code like (2), (3) or (4),
all of which obscure rather than clarify what the program is doing.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On Mon, Aug 16, 2010 at 9:53 AM, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: On Aug 7, 2010, at 9:14 PM, John Nagle wrote: The languages which have real multidimensional arrays, rather than arrays of arrays, tend to use 1-based subscripts. That reflects standard practice in mathematics. Not always -- mathematicians use whatever starting index is most convenient for the problem at hand. Yes, there are many engineering fields where index starts at 0. Partly for the reason you have stated concerning polynomials, especially since this extend to series, which are pervasive in numerical computing. In linear algebra, though, I remember to have always noted matrices indexes in the [1,n] range, not [0,n-1]. In general, I suspect this is much more a tradition than any kind of very reasoned thinking (and conversely, I find most arguments for 0-indexing and against one-indexing rather ... unconvincing. What's awkward is when you have to constantly change from one to the other). cheers, David -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On 2010-08-15, John Nagle na...@animats.com wrote: In retrospect, C's pointer=array concept was a terrible mistake. C arrays are not pointers. -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
In article i4b770$hv...@localhost.localdomain, Martin Gregorie mar...@address-in-sig.invalid wrote: Say you have intensity data captured from an X-ray goniometer from 160 degrees to 30 degrees at 0.01 degree resolution. Which is most evil of the following? 1) real intensity[16000:3000] for i from lwb intensity to upb intensity plot(i/100, intensity[i]); How about (totally inventing syntax as I go along): 5) real intensity[160.0 : 30.0 : 0.01] for index, value in intensity: plot(index, value) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
In message roy-ee1b7f.21001716082...@news.panix.com, Roy Smith wrote: 5) real intensity[160.0 : 30.0 : 0.01] How many elements in that array? a) 2999 b) 3000 c) neither of the above -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
In article i4cqg0$ol...@lust.ihug.co.nz, Lawrence D'Oliveiro l...@geek-central.gen.new_zealand wrote: In message roy-ee1b7f.21001716082...@news.panix.com, Roy Smith wrote: 5) real intensity[160.0 : 30.0 : 0.01] How many elements in that array? a) 2999 b) 3000 c) neither of the above c) neither of the above. More specifically, 13,001 (if I counted correctly). -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On 8/16/10 9:29 PM, Roy Smith wrote: In articlei4cqg0$ol...@lust.ihug.co.nz, Lawrence D'Oliveirol...@geek-central.gen.new_zealand wrote: In messageroy-ee1b7f.21001716082...@news.panix.com, Roy Smith wrote: 5) real intensity[160.0 : 30.0 : 0.01] How many elements in that array? a) 2999 b) 3000 c) neither of the above c) neither of the above. More specifically, 13,001 (if I counted correctly). 13000, actually. Floating point is a bitch. [~/Movies] |1 import numpy [~/Movies] |2 len(numpy.r_[160.0:30.0:-0.01]) 13000 -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On Mon, 16 Aug 2010 22:56:20 -0500, Robert Kern wrote: On 8/16/10 9:29 PM, Roy Smith wrote: In articlei4cqg0$ol...@lust.ihug.co.nz, Lawrence D'Oliveirol...@geek-central.gen.new_zealand wrote: In messageroy-ee1b7f.21001716082...@news.panix.com, Roy Smith wrote: 5) real intensity[160.0 : 30.0 : 0.01] How many elements in that array? a) 2999 b) 3000 c) neither of the above c) neither of the above. More specifically, 13,001 (if I counted correctly). 13000, actually. Floating point is a bitch. [~/Movies] |1 import numpy [~/Movies] |2 len(numpy.r_[160.0:30.0:-0.01]) 13000 Actually, the answer is 0, not 13000, because the step size is given as 0.01, not -0.01. import numpy len(numpy.r_[160.0:30.0:-0.01]) 13000 len(numpy.r_[160.0:30.0:0.01]) 0 -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
In message 4c5db0ae$0$1641$742ec...@news.sonic.net, John Nagle wrote: The languages which have real multidimensional arrays, rather than arrays of arrays, tend to use 1-based subscripts. That reflects standard practice in mathematics. Actually I’d go one better, and say that the languages that have real multidimensional arrays allow you to explicitly specify both the lower and upper bounds of each dimension. E.g. Ada, ALGOL 68. Heck, even Pascal allowed you to do that. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
In message mailman.2071.1281719688.1673.python-l...@python.org, Thomas Jollans wrote: Where it all started is that 0-based indexing gives languages like C a very nice property: a[i] and *(a+i) are equivalent in C. From a language design viewpoint, I think that's quite a strong argument. It would be if pointers and arrays were the same thing in C. Only they’re not, quite. Which somewhat defeats the point of trying to make them look the same, don’t you think? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
In message mailman.2084.1281741048.1673.python-l...@python.org, Ian Kelly wrote: The ability to change the minimum index is evil. Pascal allowed you to do that. And nobody ever characterized Pascal as “evil”. Not for that reason, anyway... -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On Aug 15, 2010, at 1:00 PM, Lawrence D'Oliveiro wrote: It would be if pointers and arrays were the same thing in C. Only they’re not, quite. Which somewhat defeats the point of trying to make them look the same, don’t you think? How are they not the same? The code snippet (in C/C++) below is valid, so arrays are just pointers. The only difference is that the notation x[4] reserves space for 4 (consecutive) ints, and the notation *y doesn't. int x[4]; int *y = x; Moreover, the following is valid (though unsafe) C/C++: int *x; int y = x[4]; Cheers, Roald -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On Aug 7, 2010, at 9:14 PM, John Nagle wrote: FORTRAN, MATLAB, and Octave all use 1-based subscripts. The languages which have real multidimensional arrays, rather than arrays of arrays, tend to use 1-based subscripts. That reflects standard practice in mathematics. True, but that something is standard mathematical notation doesn't mean it's preferable. For example, I have never seen keyword arguments in mathematical notation, and it's definitely not standard practice, but nobody would drop them in favor of standard mathematical notation. In fact, I think, regularly mathematical notation can be improved by standard programming notation. Moreover, I don't see what's so nice about 'real' multidimensional arrays; the way to construct multidimensional arrays from one- dimensional ones is more orthogonal. And you never *have* to think about them as being one-dimensional, it's just a bonus you can (sometimes) profit from. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On Sun, Aug 15, 2010 at 4:55 AM, Roald de Vries downa...@gmail.com wrote:
On Aug 15, 2010, at 1:00 PM, Lawrence D'Oliveiro wrote:
It would be if pointers and arrays were the same thing in C. Only they’re
not, quite. Which somewhat defeats the point of trying to make them look
the
same, don’t you think?
How are they not the same?
The code snippet (in C/C++) below is valid, so arrays are just pointers. The
only difference is that the notation x[4] reserves space for 4 (consecutive)
ints, and the notation *y doesn't.
int x[4];
int *y = x;
Moreover, the following is valid (though unsafe) C/C++:
int *x;
int y = x[4];
Just to demonstrate that they are different, the following code
compiles cleanly:
int main() {
int *pointer;
pointer++;
return 0;
}
While this does not:
int main() {
int array[0];
array++;
return 0;
}
Geremy Condra
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On Aug 15, 2010, at 2:16 PM, geremy condra wrote:
On Sun, Aug 15, 2010 at 4:55 AM, Roald de Vries downa...@gmail.com
wrote:
On Aug 15, 2010, at 1:00 PM, Lawrence D'Oliveiro wrote:
It would be if pointers and arrays were the same thing in C. Only
they’re
not, quite. Which somewhat defeats the point of trying to make
them look
the
same, don’t you think?
How are they not the same?
The code snippet (in C/C++) below is valid, so arrays are just
pointers. The
only difference is that the notation x[4] reserves space for 4
(consecutive)
ints, and the notation *y doesn't.
int x[4];
int *y = x;
Moreover, the following is valid (though unsafe) C/C++:
int *x;
int y = x[4];
Just to demonstrate that they are different, the following code
compiles cleanly:
int main() {
int *pointer;
pointer++;
return 0;
}
While this does not:
int main() {
int array[0];
array++;
return 0;
}
Interesting! Thanks for the lesson ;-).
Cheers, Roald
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
Roald de Vries wrote:
div class=moz-text-flowed style=font-family: -moz-fixedOn Aug
15, 2010, at 2:16 PM, geremy condra wrote:
On Sun, Aug 15, 2010 at 4:55 AM, Roald de Vries downa...@gmail.com
wrote:
On Aug 15, 2010, at 1:00 PM, Lawrence D'Oliveiro wrote:
It would be if pointers and arrays were the same thing in C. Only
they’re
not, quite. Which somewhat defeats the point of trying to make them
look
the
same, don’t you think?
How are they not the same?
The code snippet (in C/C++) below is valid, so arrays are just
pointers. The
only difference is that the notation x[4] reserves space for 4
(consecutive)
ints, and the notation *y doesn't.
int x[4];
int *y =x;
Moreover, the following is valid (though unsafe) C/C++:
int *x;
int y = x[4];
Just to demonstrate that they are different, the following code
compiles cleanly:
int main() {
int *pointer;
pointer++;
return 0;
}
While this does not:
int main() {
int array[0];
array++;
return 0;
}
Interesting! Thanks for the lesson ;-).
Cheers, Roald
That particular example doesn't really matter; it just shows that array
is a *const* pointer.
One that does matter, sometimes drastically, is sizeof(array) vs.
sizeof(pointer).
One interesting other effect of the compiler (nearly always) treating
pointers and arrays the same is expressions like:
int hexdigit = ...something...
char ch = 0123456789abcdef[hexdigit];
char ch2 = hexdigit[0123456789abcdef;
both are valid assignments, and equivalent to
char ch3 = hexdigit + (0123456789abcdef);
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On 8/15/2010 4:00 AM, Lawrence D'Oliveiro wrote: In messagemailman.2071.1281719688.1673.python-l...@python.org, Thomas Jollans wrote: Where it all started is that 0-based indexing gives languages like C a very nice property: a[i] and *(a+i) are equivalent in C. From a language design viewpoint, I think that's quite a strong argument. It would be if pointers and arrays were the same thing in C. Only they’re not, quite. Which somewhat defeats the point of trying to make them look the same, don’t you think? In retrospect, C's pointer=array concept was a terrible mistake. It's a historical artifact; early C (pre KR, as shipped with research UNIX V6 and PWB) had no notion of typing; all struct pointers were interchangeable and elements of a struct were just offsets of a pointer. That was fixed, but arrays weren't. The fundamental problem with array=pointer is that it results in lying to the language. Consider the declaration of read: int read(int fd, char* buf, size_t n); This is a a lie. buf is not a pointer to a character. It's an array. And, the bad part, the compiler doesn't know how big it is. The syntax should have been something like int read(int fd, char[n] buf, size_t n); This says the type of the argument is an array of char of length n, and it's being passed by reference. read then knows how big buf is. This design error in C is the cause of most buffer overflow crashes and security holes. John Nagle -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
Ian Kelly wrote: On Fri, Aug 13, 2010 at 11:53 AM, Martin Gregorie mar...@address-in-sig.invalid wrote: real sample[-500:750]; Ugh, no. The ability to change the minimum index is evil. Not always; it can have its uses, particularly when you're using the array as a mapping rather than a collection. Pascal had a nice feature where you could use any ordinal type as an array index, and sometimes it was handy to have things like an array indexed by the characters 'A' to 'Z', or the values (Red, Green, Blue). Typically you didn't need to do arithmetic on the indices in those case, though. Python addresses this by having separate types for sequences and mappings. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
Roald de Vries wrote: On Aug 15, 2010, at 1:00 PM, Lawrence D'Oliveiro wrote: Which somewhat defeats the point of trying to make them look the same, don’t you think? How are they not the same? One way to see that they're not *exactly* the same is the fact that sizeof(python rocks) is 13, not sizeof(char *). Arrays exist as a distinct concept in the type system. What is true is that when you use the name of an array in an expression, it evaluates to a pointer to its first element. And array indexing is defined in terms of what happens to the resulting pointer, rather than being done directly on the array itself. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On Aug 7, 2010, at 9:14 PM, John Nagle wrote: The languages which have real multidimensional arrays, rather than arrays of arrays, tend to use 1-based subscripts. That reflects standard practice in mathematics. Not always -- mathematicians use whatever starting index is most convenient for the problem at hand. For example, the constant term of a polynomial is usually called term 0, not term 1. So to a mathematician, an array being used to hold polynomial coefficents would most naturally be indexed from 0. I suspect that part of the reason Fortran uses 1-based indexing is that people hadn't had enough experience with high-level languages back then to realise the awkwardness it often leads to, and they were relying on common sense. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
In article 8crg0effb...@mid.individual.net, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: Not always -- mathematicians use whatever starting index is most convenient for the problem at hand. Which may be 0, 1, or something else. There are plenty of situations, for example, where you might want to use both positive and negative indices. Which work with Python lists, but not the way a mathematician would expect :-) In general, I've found, Because that's the way they do it in math, to be an unreliable guide to, How should we do it in a programming language? It's often a reasonable place to start, but there are other considerations. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
In message 8crg0effb...@mid.individual.net, Gregory Ewing wrote: For example, the constant term of a polynomial is usually called term 0, not term 1. That is not some kind of ordinal numbering of the terms, that is the power of the variable involved. And polynomials can have negative powers, too. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
... However, the killer reason is: it's what everybody else does. If this were really true, lists would be 1-based. I go back to WATFOR; and Fortran (and I believe Cobol and PL/I, though I'm not positive about them) were 1-based. (Now that I think about it, PL/I, knowing IBM, could probably be set to use either) Back then, everyone else was doing 1-based lists. In my opinion, the reason lists are 0-based started with a lazy programmer who decided that his own comfort (using 0-based addressing at the machine level and not having to translate the high-level 1- based language index into a low-level 0-based index) was paramount over teaching the language and having it make sense in the real world. After all, not even Brian Kernighan thinks books start on page 0. I'm not singling out C in this case because it is a relatively low- level language for low-level programmers and 0-based lists make perfect sense in that context. But then every compiler/interpreter programmer after that stopped caring about it. I smile every time I see the non-nonsensical sentence The first thing, therefore, is in thing[0] in a programming language learning book or tutorial. I laugh every time I hear someone defend that as common sense. Every three year old watching Sesame Street knows counting things starts with '1', not '0'. When you were three and you counted your blocks, you started with '1', not '0'. The whole rest of the world understands that implicitly, even if their counting starts '1', '2', 'many'. 0-based lists are NOT common sense. They only make sense to the programmers of computer languages, and their fanbois. There may be loads of reasons for it, but don't throw common sense around as one of them. Den -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On 2010-08-13 17:27, Den wrote: There may be loads of reasons for it, but don't throw common sense around as one of them. It's a good thing then that I didn't: ... However, the killer reason is: it's what everybody else does. Where it all started is that 0-based indexing gives languages like C a very nice property: a[i] and *(a+i) are equivalent in C. From a language design viewpoint, I think that's quite a strong argument. Languages based directly on C (C++, Objective C, ...) can't break with this for obvious reasons, and other language designers/implementers imitated this behaviour without any good reason to do so, or not to do so. In higher-level languages, it doesn't really matter. 1-based indexing might seam more intuitive, but in the end, it's just another thing you have to learn when learning a language, like commas make tuples, and somebody studying a programming language learns it, and gets used to it if they aren't used to it already. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On 2010-08-13, Thomas Jollans tho...@jollans.com wrote: 1-based indexing might seam more intuitive, but in the end, it's just another thing you have to learn when learning a language, like commas make tuples, and somebody studying a programming language learns it, and gets used to it if they aren't used to it already. I think the main reason zero-based indexing is chosen in higher level languages is the following useful property: x[n:m] + x[m:len(x)] == x -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On Fri, 13 Aug 2010 19:14:44 +0200, Thomas Jollans wrote: Where it all started is that 0-based indexing gives languages like C a very nice property: a[i] and *(a+i) are equivalent in C. From a language design viewpoint, I think that's quite a strong argument. Languages based directly on C (C++, Objective C, ...) can't break with this for obvious reasons, and other language designers/implementers imitated this behaviour without any good reason to do so, or not to do so. In higher-level languages, it doesn't really matter. 1-based indexing might seam more intuitive. In a higher level language 1-based indexing is just as limiting as 0- based indexing. What you really want is the ability to declare the index range to suit the problem: in Algol 60 it is very useful to be able to declare something like: real sample[-500:750]; and Algol 68 went even further: flex [1:0] int count where the array bounds change dynamically with each assignment to 'count'. Iteration is supported by the lwb and upb operators which return the bounds of an array, so you can write: for i from lwb count to upb count do -- martin@ | Martin Gregorie gregorie. | Essex, UK org | -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On 08/10/10 06:36, Bartc wrote: And if the context is Python, I doubt whether the choice of 0-based over a 1-based makes that much difference in execution speed. And I doubt anyone cares about execution speed when deciding whether to use 1-based or 0-based array. The reason why you want to choose the alternative that use less conversion to the other system is to simplify the source code. Many common mathematical/physics/economics formulas are expressed much simply if we use 0-based counting: * arithmetic series: - 1-based: s(n) = a + (n - 1) * d - 0-based: s(n) = a + n * d * geometric series: - 1-based: g(n) = a * r**(n - 1) - 0-based: g(n) = a * r**n * equation of motion: - 1-based: x(t) = a + 1/2 * a * (t - 1)**2 - 0-based: x(t) = a + 1/2 * a * t**2 * exponential growth/decay: - 1-based: d(t) = a * e**(k * (t - 1)) - 0-based: d(t) = a * e**(k*t) In fact, most textbooks would already uses 0-based formula for some of these formulas already. Most physics and economic textbooks would show the base 0 variation of the formula, and refers to t=0 as the point in time where the event started. I often used this model of thinking for 0-based array indices (and negative indices): -7 -6 -5 -4 -3 -2 -1 +---+---+---+---+---+---+---+ | c | h | a | r | l | i | e | +---+---+---+---+---+---+---+ 0 1 2 3 4 5 6 (7) instead of: In short, the choice of 0-based array is of practical purpose, rather than historical purpose. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
Sorry the message gets cuts off by an accidental press of send button. On 08/14/10 04:31, Lie Ryan wrote: On 08/10/10 06:36, Bartc wrote: And if the context is Python, I doubt whether the choice of 0-based over a 1-based makes that much difference in execution speed. And I doubt anyone cares about execution speed when deciding whether to use 1-based or 0-based array. The reason why you want to choose the alternative that use less conversion to the other system is to simplify the source code. Many common mathematical/physics/economics formulas are expressed much simply if we use 0-based counting: * arithmetic series: - 1-based: s(n) = a + (n - 1) * d - 0-based: s(n) = a + n * d * geometric series: - 1-based: g(n) = a * r**(n - 1) - 0-based: g(n) = a * r**n * equation of motion: - 1-based: x(t) = a + 1/2 * a * (t - 1)**2 - 0-based: x(t) = a + 1/2 * a * t**2 * exponential growth/decay: - 1-based: d(t) = a * e**(k * (t - 1)) - 0-based: d(t) = a * e**(k*t) In fact, most textbooks would already uses 0-based formula for some of these formulas already. Most physics and economic textbooks would show the base 0 variation of the formula, and refers to t=0 as the point in time where the event started. I often used this model of thinking for 0-based array indices (and negative indices): -7 -6 -5 -4 -3 -2 -1 +---+---+---+---+---+---+---+ | c | h | a | r | l | i | e | +---+---+---+---+---+---+---+ 0 1 2 3 4 5 6 (7) instead of: so to repeat, I often use this model of thinking: -7 -6 -5 -4 -3 -2 -1 +---+---+---+---+---+---+---+ | c | h | a | r | l | i | e | +---+---+---+---+---+---+---+ 0 1 2 3 4 5 6 (7) instead of: -7 -6 -5 -4 -3 -2 -1 +---+---+---+---+---+---+---+ | c | h | a | r | l | i | e | +---+---+---+---+---+---+---+ 0 1 2 3 4 5 6 that is, the indices refers to the gap between the array entries. The gap index model highlights the naturalness of using 0-based array, negative indices, array slicing, and half-open. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On 8/13/2010 11:27 AM, Den wrote: I smile every time I see the non-nonsensical sentence The first thing, therefore, is in thing[0] in a programming language learning book or tutorial. I laugh every time I hear someone defend that as common sense. If one thinks in terms of slicing at gap positions, the 'proper' indexes would range from 0.5 (average of 0 and 1) to n-0.5. For convenience, we round down or up. To put it another way, seq[n:n+1] is abbreviated as either seq[n] or seq[n+1]. Put this way, the first choice is at least as sensible as the second. Given that Python allows indexing from both end, I prefer 0,1,2,... and -1,-2,-3,... to 1,2,3... and 0,-1,-2,... or 1,2,3,... and -1,-2,-3. As someone else pointed out, discretizing a continuous variable starting at 0 gives 0,1,2,... so having indexes that match is handy. If a problem is formulated in terms of 1,2,3, one can simply leave the first cell blank rather than reformulate. If a problem is formulated in terms of 0,1,2,... and indexes are 1 based, then one must reformulate. Every three year old watching Sesame Street knows counting things starts with '1', not '0'. And that is the same mistake that most societies make, the mistake that put a lid on Greak math, science, and finance. All fresh counts begin with 0. Counting by people usually begins with a silent 0, just as fresh tallies begin with a blank stick or paper. But not always. For instance, lets count the people who have, up to noe, become billionaires with Python. We start with an overt 0. Now we can discuss whether the founders of Google should increase that to 2. Mechanical counting requires an overt 0. A car odometer starts at 0, not 1 and not . Have you never written a counting program? Starting with n = 1 instead of n = 0 before counting the first item would be a bad bug. There may be loads of reasons for it, but don't throw common sense around as one of them. I won't. Only a few (about 3 or 4) societies included a proper 0 in their number systems. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On Fri, Aug 13, 2010 at 11:53 AM, Martin Gregorie mar...@address-in-sig.invalid wrote: In a higher level language 1-based indexing is just as limiting as 0- based indexing. What you really want is the ability to declare the index range to suit the problem: in Algol 60 it is very useful to be able to declare something like: real sample[-500:750]; Ugh, no. The ability to change the minimum index is evil. I don't much care whether a high-level language uses 0-based or 1-based indexing, but I do care that it is consistent. On the occasions when I am forced to use Visual Basic, the single biggest wart that drives me up a wall is constantly having to figure out whether the particular thing that I am currently indexing is 0-based or 1-based. Cheers, Ian -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
Terry Reedy wrote: On 8/9/2010 11:16 AM, Grant Edwards wrote: Just for the record: I sincerely apologize for my rant. I usually don't loose control so heavily, but this Rick person makes me mad (killfile'd now) IOW, the Ugly American. No! That's not what I said. I'm myself one of those bad germans and I *entirely* agree with Mr. Reedy's comment: Stereotypically bashing Americans is as ugly and obnoxious as bashing any other ethnic group. I have traveled the world and Americans are no worse, but are pretty much the same mix of good and bad. It is certainly off-topic and inappropriate for this group. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
Ben Finney wrote: D'Arcy J.M. Cain da...@druid.net writes: No. You are giving me math and logic but the subject was common sense. Common sense is often unhelpful, and in such cases the best way to teach something is to plainly contradict that common sense. Common sense, for example, would have the Earth as a flat surface with the Sun and Moon as roughly-identically-sized objects orbiting the Earth. Is it better to pander to that common sense, or to vigorously reject it in order to teach something more useful? I could'nt agree more. If it was not for my scolarship, I would gladly think that the earth is flat and the sun is moving around. It took thousands of years for *1* man to figure out that was wrong. So if there is one thing that common sense is not helpful, then that thing is finding the Truth. JM Ignorance is the mother of all traditions (V. Hugo) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On Tue, 10 Aug 2010 13:51:17 +0200 Jean-Michel Pichavant jeanmic...@sequans.com wrote: Pardon the response to the response. I missed Ben's message. Ben Finney wrote: D'Arcy J.M. Cain da...@druid.net writes: No. You are giving me math and logic but the subject was common sense. Common sense is often unhelpful, and in such cases the best way to teach something is to plainly contradict that common sense. I even agree with you. However, the OP was claiming that zero based counting contradicted common sense and that was what I was responding to. I would never use common sense to prove anything. -- D'Arcy J.M. Cain da...@druid.net | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
1) Why do Python lists start with element [0], instead of element [1]? Common sense would seem to suggest that lists should start with [1]. Because Zero is the neutral element of addition operation. And indexes (and all adresses in computing) involve with addition much more than multiplication! That's too clear i think and that's silly to use One as first index of arrays/lists in a programming language! -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On 2010-08-07, Hexamorph hexamo...@gmx.net wrote: Lurking for long enough to know your style. Looking at your Unicode rant, combined with some other comments and your general I am right and you are wrong because you disagree with me. style, I came to the conclusion, that you are either a faschist or the perfect role model for an imperialistic, foreign culture destroying, self-praising, arrogant, ignorant moron. IOW, the Ugly American. I assure you that we here in the US are aware of the problem and do try to keep them from annoying the rest of the world by providing them with an abundance of junk food, bad television, worse movies, and a variety of sporting events tailored to their tastes. Unfortunately the advent of cheap air-travel in the latter half of the 20th century has allowed small groups of them to escape and wander about various parts of the world (mainly Europe) in search of KFCs while complaining about the toilets, the food, the money, the weather, the roads, the cars, and so on. They are easily identified by their cloathing and their believe that everybody understands English if you speak it loudly and slowly while accompanying it with exaggerated, mostly-random hand gestures. Just avoid them if possible. Don't worry, the less contact they have with furriners the happier they are (which makes one wonder why they leave their home territories -- reasearch on that topic is ongoing). Unfortunately, if you work in the hospitality industries there's not much you can do other than grit your teeth, cross you fingers, and hope you'll end up with a batch that over-tips. -- Grant Edwards grant.b.edwardsYow! Youth of today! at Join me in a mass rally gmail.comfor traditional mental attitudes! -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On 8/9/2010 11:16 AM, Grant Edwards wrote: IOW, the Ugly American. [snip hate rant] Stereotypically bashing Americans is as ugly and obnoxious as bashing any other ethnic group. I have traveled the world and Americans are no worse, but are pretty much the same mix of good and bad. It is certainly off-topic and inappropriate for this group. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On 2010-08-09, Terry Reedy tjre...@udel.edu wrote: On 8/9/2010 11:16 AM, Grant Edwards wrote: IOW, the Ugly American. [snip hate rant] Stereotypically bashing Americans I wasn't bashing Americans. I was making light of a certain type of American tourist commonly denoted by the phrase ugly american. is as ugly and obnoxious as bashing any other ethnic group. I have traveled the world and Americans are no worse, but are pretty much the same mix of good and bad. I've travelled the world as well, and I think that Americans do indeed make worse tourists than most others. I've seen a lot of European and Asian tourists in the US, and I've never seen from them the types of behavior for which the Ugly American tourists is famous. I've never been confronted here in the US by a Japanese tourist who thought that if he spoke Japanese to a store clerk loudly and slowing the clerk would understand. I've never seen European tourists trying to avoid eating American food or complaining about the electrical outlets. It is certainly off-topic and inappropriate for this group. To that I'll confess. -- Grant Edwards grant.b.edwardsYow! I feel ... JUGULAR ... at gmail.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
D'Arcy J.M. Cain da...@druid.net wrote in message news:mailman.1735.1281185722.1673.python-l...@python.org... On Sat, 07 Aug 2010 13:48:32 +0200 News123 news1...@free.fr wrote: It makes sense in assembly language and even in many byte code languages. It makes sense if you look at the internal representation of unsigned numbers (which might become an index) For a complete beginner common sense dictates differently and there might be confusion why the second element in a list has index 1. Would said beginner also be surprised that a newborn baby is zero years old or would it be more natural to call them a one year old? Zero based counting is perfectly natural. Depends whether you are counting (discrete) things, or measuring them (over a continuous range). You would start counting at 1, but start measuring from 0. -- Bartc -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
Nobody nob...@nowhere.com wrote in message
news:pan.2010.08.07.15.23.59.515...@nowhere.com...
On Sat, 07 Aug 2010 13:48:32 +0200, News123 wrote:
Common sense is wrong. There are many compelling advantages to
numbering from zero instead of one:
http://lambda-the-ultimate.org/node/1950
It makes sense in assembly language and even in many byte code languages.
It makes sense if you look at the internal representation of unsigned
numbers (which might become an index)
It also makes sense mathematically. E.g. for an MxN array stored as a
1-dimensional array, the element a[j][i] is at index
j * N + i
with zero-based indices but:
(j-1) * N + (i-1) + 1
= j * N + i - N
with one-based indices.
In other words, an extra offset to be added, in an expression already using
a multiply and add, and which likely also needs an extra multiply and add to
get the byte address of the element.
(And often, the a[j][i] expression will be in a loop, which can be compiled
to a pointer that just steps from one element to the next using a single
add.)
The indices i and j might anyway be user data which happens to be 1-based.
And if the context is Python, I doubt whether the choice of 0-based over a
1-based makes that much difference in execution speed.
(I've implemented languages that allow both 0 and 1-based indexing (and
N-based for that matter). Both are useful. But my interpreted languages tend
to use 1-based default indexing as it seems more natural and 'obvious')
IOW, if a language uses one-based indices, it will inevitably end up
converting to and from zero-based indices under the hood,
Sometimes. At the very low level (static, fixed array), the cost is absorbed
into the address calculation. At a higher level, the cost is less
significant, or there might be tricks to avoid the extra addition.
and may end up
forcing the user to do likewise if they need to do their own array
manipulation.
Lots of things require this sort of calculation, eg. how many pages are
needed to print 267 lines of text at 60 lines per page? These counts are
1-based so it's (L-1)/P+1 (integer divide), or 5 pages.
If we switch to 0-based counting, it's just L/P ('266' lines require '4'
pages), but who's going to explain that to the user?
--
Bartc
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
Not to prolong a good food fight, but IIRC, many years ago in QBasic, one could choose OPTION BASE 0 or OPTION BASE 1 to make arrays start with element [0] or element [1], respectively. Could such a feature be added to Python without significantly bloating the interpreter? Then, if starting with [0] works for you, nothing really changes. And if starting with [1] works for you, then you are not made to feel like a second-class citizen, and about as welcome as a dimwit at the Mensa meeting. Isn't Python supposed to be simple and accessible, and therefore fun? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On Sun, Aug 8, 2010 at 10:24 AM, Default User hunguponcont...@gmail.com wrote: Not to prolong a good food fight, but IIRC, many years ago in QBasic, one could choose OPTION BASE 0 or OPTION BASE 1 to make arrays start with element [0] or element [1], respectively. Could such a feature be added to Python without significantly bloating the interpreter? Then, if starting with [0] works for you, nothing really changes. And if starting with [1] works for you, then you are not made to feel like a second-class citizen, and about as welcome as a dimwit at the Mensa meeting. Isn't Python supposed to be simple and accessible, and therefore fun? Python is also about being readable and consistent. It's going to get really confusing if half the files use 1-based lists and the other half use 0-based. Is it really that hard to get used to indices running from 0 to length-1? Also, good luck getting through life without running into C, C++, C#, Visual Basic, F#, Java, Ruby, Perl, Lisp, or OCaml code. Along with all the languages that use 0-based arrays. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
Default User wrote: Not to prolong a good food fight, but IIRC, many years ago in QBasic, one could choose OPTION BASE 0 or OPTION BASE 1 to make arrays start with element [0] or element [1], respectively. Could such a feature be added to Python without significantly bloating the interpreter? Then, if starting with [0] works for you, nothing really changes. And if starting with [1] works for you, then you are not made to feel like a second-class citizen, and about as welcome as a dimwit at the Mensa meeting. If you changed the base then you'd break the standard library, unless everyone altered their code to compensate. It's all part of learning a programming language. Some have 0-based indexing, others have 1-based indexing; some have mutable strings, others have immutable strings, still others don't have 'proper' strings. Just learn to adapt. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On 2010-08-08 05:18, Dennis Lee Bieber wrote: Was it this thread where I commented that many early BASICs would allocate an eleven element array on DIM A(10) VB.net does this -- to cater for the classic VB programmer who is used to being able to index the number in brackets, and the .net framework, which uses 0-based indexing (as everything else would look silly in C#, or, especially, in C++/CLI. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python why questions
On Aug 7, 2010, at 5:46 AM, Vito 'ZeD' De Tullio wrote: Default User wrote: From the emperor's new clothes department: 1) Why do Python lists start with element [0], instead of element [1]? Common sense would seem to suggest that lists should start with [1]. http://userweb.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html I think the reason why is just historical; C uses zero-based indices. In C, an array index is an offset with respect to the pointer that the array variable actually is, so 0 makes sense (my_array[0] == *my_array). I'm not convinceed (yet) by Dijkstra's reasoning. *Maybe* if you want to describe a range with two /='s, it makes sense. But Python (nor C, nor ...) uses that notation. I agree with the OP that the first item in a list would most naturally be called item 1, and therefore have index 1. (This doesn't mean I'm in favor of 1-based indices) One of the reasons I like python so much, is that you (almost) never have to use indices. Normally you just iterate over the elements. If I ever need indices, it's a strong indication that I actually want a dictionary. Cheers, Roald -- http://mail.python.org/mailman/listinfo/python-list
