Zuckerberg To Teach 10 Million Kids 0-Based Counting

theodp writes "'Why do programmers start counting at zero?' wondered Mike Hoye, questioning the conventional programming wisdom. Code.org will soon introduce the practice to a hoped-for audience of 10 million schoolchildren as part of Computer Science Education Week's Hour of Code. In a tutorial created by engineers from Microsoft, Google, Twitter and Facebook that's intended to introduce programming to kids as young as six years old, an otherwise breezy lesson featuring look-ma-no-typing Blockly and characters out of Angry Birds and Plants vs. Zombies, a Mark Zuckerberg video introducing the concept of Repeat Loops includes an out-of-place JavaScript example that shows kids it's as easy as 0-1-2-3 to generate 4 lines of lyrics from Happy Birthday to You by using zero-based numbering with a For-loop and ternary If statement. Accompanying videos by Bill Gates on If Statements and basketball star Chris Bosh on Repeat Until Blocks show the Code.org tutorial is still a work-in-progress. That's no big deal, since CSEdWeek has pushed back the delivery date for final Hour of Code tutorials from its prior little-time-for-testing due date to Dec. 9th, the first day of a five-day period during which teachers are expected to deliver the lessons to 10 million students."

Comments

They don't.

[skywire]

Iterating through offsets beginning with zero is simply not counting. The writer is confused.

Re:They don't.

[wonkey_monkey]

This press conference is over.

Re:They don't.

[ackthpt]

This press conference is over.

The press conference began at 0 PM, where were you?

Re:They don't.

[Bozzio]

Are you referring to my ding-a-ling by any chance?
http://www.youtube.com/watch?v=p490t_6Z9aY

Re:They don't.

[ackthpt]

Iterating through offsets beginning with zero is simply not counting. The writer is confused.

I knew I was destined to be a programmer when I was introduced to Integers in elementary school. The siren song of beginning counting somewhere other than 1 entranced me.

Re:They don't.

[bsDaemon]

Why would programming want to meet kids as young as six years old?

Re:They don't.

[mpicker0]

There are plenty of software documentation sets, tutorials, etc, like this one (selected at random), that have Step 0, Step 1, etc. I think it's an attempt to be clever, in that offsets start with zero, and this is documentation about computer stuff, being read by developers. But items in a list, intended to be read by humans, shouldn't be represented by offsets, but numbered with counting numbers, that is, starting at 1.

Re:They don't.

[CastrTroy]

Speaking of iterating, I almost never need to write a loop that uses an integer index. All the programming languages I use have a "For each" construct that works with just about anything you'd want to iterate over. No more worrying about off-by-one bugs, and other such associated problems. I have trouble recalling the last time I actually used the For(i =0.... syntax.

Re:They don't.

[Anonymous Coward]

This press conference is over.

The press conference began at 0 PM, where were you?

I was at 0 Main Street.

"The corner of 0th and Null" was the joke you wanted.

Re:They don't.

[Joce640k]

Bill Gates still uses BASIC and Mark Zuckerberg uses its bastard offspring (Python). You have to excuse them for not knowing about any data structure other than the integer-indexed array.

Re:They don't.

[gweihir]

Probably not only the writer. Seems all the well-known "IT" personalities on the list never understood that little fact.

Of course counting starts at 1 and of course offsets start at 0. But you have to know what an offset actually is to understand that.

Re:They don't.

[Laxori666]

Python is one of those languages GP was talking about.

Re:They don't.

[camperdave]

Why would programming want to meet kids as young as six years old?

Because marketing thought it would be a good idea, and management agreed?

Re:They don't.

[CastrTroy]

Yeah, Also, VB.Net, the only version of "BASIC" still worth talking about also supports "For Each". I'm sure there's still people using the older versions of BASIC, but I don't think it's like COBOL, which is equally bad, but sticks around because there's so much mission critical code written in it.

Re:They don't.

[jc42]

There are plenty of software documentation sets, tutorials, etc, like this one (selected at random), that have Step 0, Step 1, etc.

And that example illustrates the usual reason for starting with step 0: The "zero" step is determining your initial state before you start doing anything. In this case, it's determining whether you should bother going on to step 1, which is pretty common. It's also common to use step 0 to list the material needed by the task.

Probably the most common real-world example is cooking recipes, which typically start with a list of ingredients. That "step" is typically not numbered, but sometimes the actual "steps" to create the food are numbered starting with 1. Or they're just in separate paragraphs, since numbering them isn't actually very useful to carry out the task. In any case, the ingredient list is usually typographically different than the rest of the recipe, and is a description of the required initial state, so it's natural to call it "step 0".

Re:They don't.

[BitZtream]

And that example illustrates the usual reason for starting with step 0: The "zero" step is determining your initial state before you start doing anything. In this case, it's determining whether you should bother going on to step 1, which is pretty common. It's also common to use step 0 to list the material needed by the task.

No, that would still be step 1. Its not natural to call it step 0. The first thing you do is get your materials and determine your state.

Its not the naught step your perform, its the FIRST.

See that word, FIRST ... comes from 1.

Re:They don't.

[i kan reed]

That's the reason we do thinks bitterly and with a ton of resentment, not why we want to do things.

Re:They don't.

[i kan reed]

VB.Net is a simple symbol substitution away from being c# though. It changed its syntax in subtle little ways between VB 6 and VB.net to do so. It's fairly trivial to write a parser that converts VB.net to C#(the other way is a tinge more complicated). I don't think it's fair to call it a true descendent of BASIC.

Re:They don't.

[fisted]

FIRST ... ONE
the similarity is overwhelming.

Re:They don't.

[TangoMargarine]

If you determine you don't have the necessary ingredients to begin the process, do you say you quit on the first step, or never started?

Re:They don't.

[pruss]

It depends what you're doing. From time to time, I need to do operations on an array entry *and* its successor (or predecessor). Also, sometimes when you're deleting entries, you want to use a numerical index and iterate from the end to the beginning of a list or array.

Re: They don't.

[turbidostato]

In other words: ordinality versus cardinality.

It seems these guys go after 6-year-olds because if they were older they'd laugh at their ignorance.

Re:They don't.

[gweihir]

Gets some basic mathematical education, then come again. Hint: Understanding what "natural numbers" are might help.

Re:They don't.

[jc42]

If you determine you don't have the necessary ingredients to begin the process, do you say you quit on the first step, or never started?

Yeah, that's the critical difference in the thinking. My calling the ingredient list "step 0" is based on the thinking that a recipe is something that tells you how make a food item. With this understanding, it makes sense that you'd consider "recipe" to mean only the actions you take that create the food item. If you already had all the ingredients in your kitchen a week ago, you wouldn't say that you started making the recipe last week. Checking the ingredient list makes nothing, so it's not a "step", it's merely a description of required initial conditions. Making the food means what you do in the kitchen when you decide what you want to eat. Buying ingredients earlier (perhaps by months because you know you'll want those ingredients some day) isn't part of making the food item. Deciding not to make a recipe because you lack a critical ingredient doesn't mean you've done the recipe's first step.

OTOH, it's reasonable that you'd interpret the ingredient list as a sort of command (though such lists never contain imperative verbs). It means "First, make sure you have the following ingredients ...." Someone who thinks that way could reasonably label the list as "step 1".

I tend to take the first approach, which is probably related to the fact that I like to keep a lot of non-perishable ingredients on hand for the food items I make often. Thus, I have a couple of bags of flour on a top kitchen shelf, several pounds of butter in a freezer in the basement, etc. I don't think of buying those ingredients as part of making a recipe. Several of the above posters apparently do, perhaps because their approach is to decide on a recipe, and then go buy the ingredients. Nothing wrong with that, if you have some good stores nearby. But it does lead to a different interpretation of that ingredient list at the top of a recipe.

Re:They don't.

[narcc]

No, that would still be step 1. Its not natural to call it step 0.

Haha! Well done!

Re:They don't.

[ccanucs]

They're really *7* years old. We started counting at 0 remember ;-)

Re:They don't.

[dl_sledding]

We started counting at 0 remember

As does the age of children... They are "0" until thier FIRST birthday, which is when they turn 1. So, the "6 year old" logic still stands.

Re:They don't.

[ccanucs]

But there's an offset too ;-) They're one year old at three months after birth. That's why we need fractional years too :-D

What is this shit?

[larry bagina]

Can I request an Editor Week?

Re:What is this shit?

[ColdWetDog]

We have editors? Where do you see that?

We don't

[Anonymous Coward]

Why do programmers start counting at zero?

We don't. We start indexing at zero (in some languages), because that's usually the offset of the first useful location in an array (ie, addr + 0).

Re:We don't

[Anonymous Coward]

Exactly. The element count of an array where only index [0] is populated is still 1.

Re:We don't

[TeknoHog]

Also, Real Programmers(TM) use Fortran where array indices start at 1 by default, though you can also define your own way.

Re:We don't

[aaribaud]

I beg to differ on two accounts:

• A. Maybe you don't, but that does not apply to "programmers", only to an imaginary set of "programmers" which you consider yourself a member of.
• B. Iterating is not necessarily entirely different from counting.

After all, the whole calculus thing stems from the latin for "small stone", which was the way to count livestock, by enumerating them. Start with no stone in hand; pick one stone per animal when you lead them some place; drop one stone per animal when you take the animals back; make sure you have no stone left, none missing either when all animals have passed. IOW... count from zero up, and then back to zero. :)

Re:We don't

[TVmisGuided]

Ada also begins iterating at 1. It's SAFER that way.

Re:We don't

[Ihlosi]

Still interesting, but show me a count of things at Zero. Physically, if there is nothing there to be represented, why is it counted?

Zero meters/miles/etc. "You haven't moved yet."

Re:We don't

[T.E.D.]

No. Ada begins iterating wherever you tell it to. You can index your arrays from -100 to 0 if you like.

Its a more useful language that way.

It is quite true though that the 0-based thing is entirely an artifact of C (and of course languages that cribbed its syntax). Thinking that's a feature of programming is a sure sign of a inexperienced programmer.

Re:We don't

[Anonymous Coward]

If you'll read the article (I know, I know) it's a feature of BCPL that C inherited, and was done to shave a few cycles off of the compilation time on some old-ass IBM mainframe so that you didn't run out of your timeshare or get bumped because the CEO of IBM wanted to run his yacht-racing simulation or whatever.

Obviously, indexing from 0 or 1 is just an arbitrary decision and you may as well index from -1 or 2 or, as the old joke goes, 0.5 as a compromise.

Re:We don't

[findoutmoretoday]

Why do programmers start counting at zero?

We don't.

Even a six year old kid knows that ... shouldn't we start at one, that's a seven year old

Re:We don't

[MtHuurne]

Physically, if there is nothing there to be represented, why is it counted?

Because people tend to decide what they count before they actually start counting. If someone asks you to count forks in an initially closed drawer, do you open the drawer and start counting, or do you answer "I cannot do that, since I don't know if the drawer contains any forks"?

Re:We don't

[Joce640k]

Ada also begins iterating at 1. It's SAFER that way.

In C++ I can define a container with an operator[] that starts wherever I want it to.

Why does nobody do it? Because we use proper iterators when we want to iterate a collection of data.

Re:We don't

[alexhs]

Reading the comments, many people are confused.

If this can help people doing less off-by-one errors ;) : cardinal vs ordinal vs nominal.

Depending on the language, an element in an array is referenced by either its ordinal value (1st element, 2nd element), or the cardinal value corresponding to an offset, that is, a difference counted in elements between the start of the array (1st element) and the considered element (0 position between requested element and start element, 1 position between requested element and start element).

Nominal values are used in enumerations and map/dictionaries (sets of key-values).

Re:We don't

[Anonymous Coward]

Since most CPU architectures offer indexed addressing modes, non-zero-based indexing would require inserting additional (and unnecessary) logic during compilation.

But that's exactly what I just said. Languages using non-zero-based indexing could (did, actually; many old languages used one-based indexing) have the same runtime speed but would require slightly longer compilation, and the difference was significant back in the punchcard and mainframe era.

Brackets holding the offset from the base pointer is a stylistic decision, not an inherent one, and in fact I've seen plenty of code that just uses a pointer offset by one address to create a one-indexed array.

Frankly, I don't care if you index at zero, one, or thirty as long as the hardware guys and the software guys can agree on it so I don't get conflicting documentation when I'm trying to interface with your driver and hardware.

Re:We don't

[sootman]

There are two kinds of programmers:
1) Those who start an index at 1
1) Those who start an index at 0

Re:We don't

[Eunuchswear]

The article is, of course, completely wrong.

BCPL was first compiled on an IBM 7094 – here’s a picture of the console, though the entire computer took up a large room – running CTSS – the Compatible Time Sharing System – that antedates Unix much as BCPL antedates C. There’s no malloc() in that context, because there’s nobody to share the memory core with. You get the entire machine and the clock starts ticking, and when your wall-clock time block runs out that’s it. But here’s the thing: in that context none of the offset-calculations we’re supposedly economizing are calculated at execution time. All that work is done ahead of time by the compiler.

This starts out wrong and gets wronger!

There’s no malloc() in that context, because there’s nobody to share the memory core with

Huh? CTSS is a time sharing system! Of course you're sharing the core.

And what the hell does malloc() have to do with anything? You can run programs on Unix that don't use malloc. You can run programs on an Apple ][ that do use malloc.

You get the entire machine and the clock starts ticking, and when your wall-clock time block runs out that’s it

This is CTSS! It had preemptive multitasking - just like Linux has preemptive multitasking. That was the whole point!

But here’s the thing: in that context none of the offset-calculations we’re supposedly economizing are calculated at execution time.

Huh? the BCPL address operators are exatly like the C ones. How could the compiler do someting like:

// pseudo BCPL code - not typographicaly correct.

var p = ...some address;
var q = ... some value;

p[q] = 22

at compile time?

Re:We don't

[cnaumann]

How many years old were you from the time you were born until your first birthday?

Re:We don't

[Bite The Pillow]

Zero, one, two. I have three stones.

That makes no sense. Or we have to re-record every sesame street episode of The Count.

Four, ah ah ah. I have 5 things. Five? You just said four, where did you get 5?

No, if this is for kids it needs to stop now.

Re:We don't

[K. S. Kyosuke]

It's not just about speed of compilation. I find reasoning about calculations with zero-based indices much easier due to the existence of modular arithmetics. Also, one-based indexing is in addition pretty screwed up without inclusive bounds, and inclusive bounds make reasoning about splitting intervals into sub-intervals hideously convoluted (how do you reasonably work with zero-length intervals that naturally occur in divide-and-conquer algorithms?)

Re:We don't

[BitZtream]

0.???? number.

A fraction of 1.

Certainly not 0.

This is not difficult.

Re:We don't

[aaribaud]

Still interesting, but show me a count of things at Zero. Physically, if there is nothing there to be represented, why is it counted?

It is counted because it was expected and missing, or it was present then removed, or it is the lack of something expected to come. Think of someone who has a dept to pay but has no money, or who has a dept to pay and just enough money, or who starts his life with no possessions yes. In all three cases, a count of zero is considered, and even though Romans did not represent zero as they did other numbers, the concept of zero money was perfectly accessible to them, either in a comparison, or as a result of subtraction, or as the start of an accumulation.

Re:We don't

[T.E.D.]

No. The creators of C were not terribly concerned about the extra compilation time - they were concerned about generating efficient code and representing it efficiently in the source.

Yes. But what made C such a universal language was the incidental fact that this made the compiler easier to implement. That allowed people to easily create C compilers for any new architecture; even all those newfangled 8-bit home computers with only 16K of addressable RAM. This is what popularized C's syntax, and thus the 0-based array.

So today, it is essentially a historical accident.

Re:We don't

[aaribaud]

Zero, one, two. I have three stones. That makes no sense.

That's because you're mistaking the states and transitions. The right description is "I have zero stone. I pick a stone. I have one stone. I pick a stone. I have two stones. I pick a stone. I have three stones and there a no stones left to pick". IOW, you see the three transition, or actions, of counting "one", "two" and "three", but you map these actions to the first three states (thus ending on the third state) instead of placing them between the four states (thus ending on the fourth one).

Re:We don't

[tlambert]

No. The creators of C were not terribly concerned about the extra compilation time - they were concerned about generating efficient code and representing it efficiently in the source.

Yes. But what made C such a universal language was the incidental fact that this made the compiler easier to implement.

Except the first machines C ran on didn't have an "add unity to memory" instruction unless you got out the wire wrap tools and made one, so this excuse doesn't work.

The real reason is that variables and arrays actually take up memory, and if you understand this fact, then you will naturally gravitate toward using a 0 offset, whereas if you don't, then you probably learned programming using a language that hides the underlying memory allocations from you. Which is why anyone who wants to claim they are a programmer should learn at least one assembly language, so that they understand that memory is just that free stuff, and that you actually have to allocate backing store for variables.

Re:We don't

[vux984]

It is quite true though that the 0-based thing is entirely an artifact of C (and of course languages that cribbed its syntax).

Its not an "artifact of C" its an artifact of reality.

If you allocate 10 bytes at address X, then:

the first one is going to be at address X, the second one is address X+1, etc.

The x[y] syntax then reduces to address x + y

And so x[0] is the byte at x, x[1] is the byte at x+1, etc.

Now you could 1 base the indexes, where x[1] resolves to address of x, but the implementation of that is:

x + 1 - 1, and x[y] in general becomes x + y - 1

That's an extra subtraction instruction on every single array access.

For larger datatypes it becomes:

x + y*sizeof(type) for zero based and
x + (y-1)*sizeof(type) for one based arrays

That's going to be true for any language, and the question is posed to every language designer: either the programmer counts from zero, or every array access in the language has a subtraction added to it.

For C, which is designed to be a bare bones close to the hardware language the decision was a nobrainer, but even for higher level languages its always a choice between a performance hit, or using zero based indexing.

Another wrinkle is that if you use 1 based indexing, then x[0] is undefined.

Another wrinkle is that if you use 1 based indexing then the maximum length of an array was reduced by 1.

No. Ada begins iterating wherever you tell it to. You can index your arrays from -100 to 0 if you like.

I don't deny that it's useful, but Ada does that by effectively adjusting all the indexes to zero based behind the scenes.

"Thinking that's a feature of programming is a sure sign of a inexperienced programmer."

No, only an inexperienced programmer would not understand that zero based indexing is the 'natural' indexing, and that anything else requires extra processing.

Re:We don't

[Alomex]

Now you could 1 base the indexes, where x[1] resolves to address of x, but the implementation of that is:

x + 1 - 1, and x[y] in general becomes x + y - 1

Or you can create a second value called

x_base=x-1

and instead of computing

x+1-1

you compute

x_base+1

with no extra subtraction and now you count like humans do.

That's going to be true for any language, and the question is posed to every language designer: either the programmer counts from zero, or every array access in the language has a subtraction added to it.

Oops.

Re:We don't

[Joce640k]

They still are, for the most part, either pointer typedefs or wrappers around pointers.

Nope.

In VC++ they're objects which are range-checked, become invalid if the container changes in a way that invalidates them, etc. There's no way to set them to 'null'. You can't assign an iterator for one container the value of an iterator from a different container. Operator[] also behaves like at() (will throw an exception if the index is out of range).

In short: Anything that can be checked, is (and has been by default since VC++2008), even in 'release' compiles.

You can have 'raw pointers' if you want them (extra speed!) but you have to ask for them with a special #define.

See: http://msdn.microsoft.com/en-us/library/aa985896(v=vs.90).aspx

Re:We don't

[vux984]

create a second value x_base=x-1

Where is x_base stored? What if I pass an array as a parameter? Do you pass x_base on the stack with it it? What it if I pass a pointer to an array? What if I serialize and deserialize it?

What if I recursively process an array by passing references to sub-arrays? Do you create x_base on the fly at every level of recusion for every pointer that gets passed?

That doesn't change the observation that zero based is the natural order of things for a computer implementation. Your x_base solution is just trying to mitigate the performance hit, (and is only partially successful). It doesn't counter the argument.

Oops.

Indeed.

Re:We don't

[luis_a_espinal]

No. Ada begins iterating wherever you tell it to. You can index your arrays from -100 to 0 if you like.

Its a more useful language that way.

It is quite true though that the 0-based thing is entirely an artifact of C (and of course languages that cribbed its syntax). Thinking that's a feature of programming is a sure sign of a inexperienced programmer.

I'm ambivalent towards that feeling. I do prefer languages like Ada that allows you to define logically sound, problem-specific index ranges (plus, what is not to love about Ada's strong-as-nails range checking capabilities, but I digress here, I know.)

But for better or for worse (I tend to think the later), C-like syntax with zero-base-indexing is pretty much the de-facto way of doing things in the programming world, and it is one of the first things programming students struggle with. It is not brain-twisting, but it is certainly not the normal mode of thinking for the uninitiated.

So it has become a feature of programming in general. Whether that is a good or a bad feature, that is a type of value judgement that I rather not do since those rarely lead to anything of substantial constructive value for the workings of everyday things.

Re:We don't

[firewrought]

Ada begins iterating wherever you tell it to. You can index your arrays from -100 to 0 if you like. Its a more useful language that way.

Useful until you need to write a method that accepts such an array... then you have to use LBOUND() and UBOUND() (or the Ada equivalents) and write slightly more abstract code. That's a slight reduction in readability for the vast majority of cases.

Thinking [zero-based indexing] is a feature of programming is a sure sign of a inexperienced programmer.

It's the easiest option, given all the tradeoffs (see other responses to this thread).

Re:We don't

[vux984]

In the cloud?

Some sort of joke? I missed it.

Oh no, we might have to treat it like a struct, the horror, the humanity.

Wait, what are you storing in the struct? Remember, X is the address of the array, and x_base is address-1 so that you can add n for x[n] to get the element. You are NOT planning to actually store x_base in the struct are you?

You've just suggested we implement a simple array as a struct that contains a pointer to an address outside the struct so that we can add offsets to it to get addresses back inside the struct!!

How you can't see that this is a terrible idea and a lot more complicated I can't understand. For example, now you can't pass the array (now a struct) by value, or make a simple copy of it by just doing a memcpy. You'd have to manually fix the x_base otherwise it'll point to the original structure.

Performance-wise then, recursive calls are no better than they were before because you still have to recalculate x_base for each copy placed on the stack. Same overhead as just recalculating x_base on the fly in each call.

What did you think it was accomplishing exactly?

I've looked into this issue for a long time
The rest of your comments show equal lack of thought.

Yeah. I'm going to have to disagree with you here.

and for every piece of code that works better with a zero based array I can show you another that works best with one based array, so in the end is a wash. Either one is fine.

Look, zero based indexing is the natural implementation. You are jumping through serious contortions just to TRY and cram one based indexing into it, and you aren't even succeeding with a compelling easy to use implementation.

Ruining an arrays simple memory copy semantics just so you can count from one is probably the most poorly thought out suggestion I've heard in a while.

You might as well just go whole hog Ada and specify index extents, because its pretty much the same amount of EXTRA work. Its not a bad idea, but make no mistake, it is extra work.

0 based indexing is the least work
anything else is extra work to implement
ergo 0 based indexing is the natural state

what I'm saying is that is ridiculous to assert that they have to be there or that they are even preferable.

All your contortions just hide the fact that they are zero based to the machine from the programmer. That doesn't change the fact that they are 0 based in the final analysis.

I myself don't know that it preferable, because that's how the hardware works. It wasn't a "choice" to make things zero based. They just are. We could jump through some hoops to try and hide that from the programmer, but their is a complexity cost to that in space (memory), and time (performance).

Re:We don't

[vux984]

The abstract concept of a type and the implementation details of that type are not the same thing, although they are both important for a programmer to know.

Agreed.

Languages that have a richer abstract model for arrays, rather than having arrays be merely syntaxic sugar for pointer arithmetic, also allow far more static analysis, allowing opportunities for the elimination, optimization or parallelization of processing that a C compiler would struggle to identify.

That tries to argue the point by suggesting that a richer language and more abstract models hides the implementation details. It hides the implementation detail that its still zero based.

Things are still zero based. You can jump through some hoops to try and hide this from the programmer if you want, but that's all you are doing, and if the programmer ever has to dig into the real guts of what's going on he or she is faced with the cold reality that everything is zero based behind the scenes.

And its not just arrays. Its strings. Its the virtual pointer table internal to a c++ class object instance. If they dig all the way down to assembly language its the stack, its the member offsets of class/object members. Anything and everything that uses offsets.

If we want to mostly hide that for programmer convenience in high level languages that's fine. But lets not pretend its some "artifact of C". Its how computers really work. And a good programmer should know that, even they use a higher level language where they don't have to think about it most of the time.

Re:We don't

[dkf]

Real Programmers(TM) use Fortran

What about Integer Programmers? (Hey, I declared it so I can do that, yes?)

Re:We don't

[maxwell demon]

Where is x_base stored?

Where you would otherwise have stored x?

Anyway, the reasonable choice it to let the user choose the lower index according to his needs. Because if the index numbers you get are 1-based, all your 0-based arrays do is to move the subtraction of 1 from being created by the compiler to being explicitly written by the programmer. Which doesn't make the code the slightest bit more efficient.

There are many cases where 0-based indexing is just the right choice, but there are also cases where 1-based indexing is more natural, and there are even cases where you'd start somewhere else (because your numbers happen to start at that value).

Also, making all arrays 0-based is a premature optimization, which is the root of all evil.

Re:We don't

[maxwell demon]

The abstract concept of a type and the implementation details of that type are not the same thing, although they are both important for a programmer to know.

Agreed.

But obviously not understood:

Languages that have a richer abstract model for arrays, rather than having arrays be merely syntaxic sugar for pointer arithmetic, also allow far more static analysis, allowing opportunities for the elimination, optimization or parallelization of processing that a C compiler would struggle to identify.

That tries to argue the point by suggesting that a richer language and more abstract models hides the implementation details. It hides the implementation detail that its still zero based.

No. The array is completely a language-level concept. At the machine-level, there are no arrays, neither zero-based ones, nor otherwise. You just have memory addresses and arithmetic operations. Zero-based arrays enable a particularly simple mapping between both (but not as simple as you seem to imply, because for almost all arrays, you'll have to do a multiplication with the array element size, which probably costs much more performance than the addition of 1).

Things are still zero based. You can jump through some hoops to try and hide this from the programmer if you want, but that's all you are doing, and if the programmer ever has to dig into the real guts of what's going on he or she is faced with the cold reality that everything is zero based behind the scenes.

No. It is trivial to code an 1-based array (or a 42-based array) in assembly: Instead of the true address of your array, use a value that differs by the element size (or 42 times the element size) to denote your array. You may need to rely on overflow-wrapping to do this, but that's OK, because overflow-wrapping is well-defined in assembly. Note again that the array is not in the computer (in case of assembly, it is not even really in the assembly code), but only in your interpretation of what the code does. The code itself does nothing but arithmetic and indirect memory accesses.

And its not just arrays. Its strings. Its the virtual pointer table internal to a c++ class object instance. If they dig all the way down to assembly language its the stack, its the member offsets of class/object members. Anything and everything that uses offsets.

You just proved that you don't have understand C++'s object model. What the virtual table contains is function pointers pointing to member functions of the object (those are ordinary addresses, not offsets). It may in addition contain an offset of the object as base object in a derived object (that's not the only possible implementation, but probably the most common; if it's a complete object, those offsets are of course all zero). But it never contains offsets of members (well, strictly speaking you can put whatever you want into a virtual table because it is not specified by the standard, but putting member offsets there would just be a waste of resources).

If we want to mostly hide that for programmer convenience in high level languages that's fine. But lets not pretend its some "artifact of C". Its how computers really work. And a good programmer should know that, even they use a higher level language where they don't have to think about it most of the time.

Since the computer doesn't know arrays at the fundamental level, every property of an array (including its existence) is an artefact of the language.

Re:We don't

[maxwell demon]

Zero, one, two. I have three stones.

That makes no sense.

Mathematically, it does: The set-theoretic definition of the natural numbers (and more generally, the ordinals, which also include infinite numbers) is that every number is the set of all preceding numbers. So the number three is the set containing exactly the numbers zero, one and two.

So he enumerates the elements of the number of stones ("zero, one, two") and then tells the name of that number ("three").

Re:We don't

[maxwell demon]

There's also a third kind:

42) Those who start their array at whatever index is convenient for their problem at hand.

Re:We don't

[fatphil]

Everything you've listed is *an artifact of C*, at least in the context of the gamut of languages also thus far mentioned.

What is "allocating" and "an address" in LISP? Or in Forth? Or in prolog? You're too stuck in C-think to realise how different other languages are, and how Algoloid-specific your knowledge is.

Re:We don't

[Modern Primate]

Thanks for this. As an inexperienced programmer I appreciate when unintuitive things are simply explained.

Re:We don't

[vux984]

I don't disagree with everything you said.

You misunderstood what I wrote about the virtual pointer table. The elements of the pointer table itself is accessed by offset. (its an array of function pointers) Yes the *contents* of the table are function pointers.

For someone who clearly knows C++ much better than most, I'm surprised you didn't realize what I meant.

Since the computer doesn't know arrays at the fundamental level, every property of an array (including its existence) is an artefact of the language.

At the fundamental level, computer memory itself is an array. Its pretty much the ONLY thing the computer does know.

The code itself does nothing but arithmetic and indirect memory accesses.

On physical arrays of memory.

The properties of language array abstractions are mapped to that physical array.

Because the physical array is zero based, any language mapping of the abstract concept on to memory is either going to inherit that, or do extra work to hide it.

No. It is trivial to code an 1-based array (or a 42-based array) in assembly: Instead of the true address of your array, use a value that differs by the element size[...].

So instead of using the address, which you start with, you do something extra.

And are you REALLY advocating that passing an address to "not the array" and relying on adding indexes to that along with possibly overflow arithmetic to result in an address that is in the array is as "simple" and "trivial" as 0 based indexing?

In any case through this discussion it seems to reveal that my argument that 0 based indexing is natural rests on the assumption and agreement that physical memory itself is arranged / accessed as zero based array(s).

You seem to argue that arrays are purely a language construct. I disagree with that.

Re:We don't

[vux984]

Everything you've listed is *an artifact of C*, at least in the context of the gamut of languages also thus far mentioned.

Everything is an artifact of the hardware. The fundamental properties of the computer itself. C is just closer to the hardware. Its not artifacts of C its artifacts of the hardware.

You're too stuck in C-think to realise how different other languages are, and how Algoloid-specific your knowledge is.

I've worked with LISP and ML and Smalltalk and XSL and SQL... but that's beside the point. I'm not stuck in C-think. I'm "stuck" in assembler and binary think; you know the actual hardware itself. Registers and opcodes, where memory itself is just an array of cells. You mistake it as "C-think" because C is quite close to the hardware, but the point is that zero based counting is not an aritfact of C, its an artifact of the hardware itself, its reflected in C because C is close to the hardware.

What is "allocating" and "an address" in LISP? Or in Forth? Or in prolog?

The further from the hardware you get the less of it you see. But LISP uses zero based counting (AREF, CHAR). And numbering conventionally begins with zero in Forth too.

Re:We don't

[maxwell demon]

Unlike arrays, memory may have arbitrary holes. For example, most 8086 PCs had a hole between the end of RAM and the beginning of ROM. Moreover, each address may or may not correspond to a memory cell; it's purely the hardware which decides which addresses correspond to available memory cells.

Anyway, address 0 is no special in this regard, unless there's something in the processor which expects memory there; but that's true for any address where the processor expects something. For example, the 8086 expects to be able to read instructions starting at address FFFF0 (note that 8086 physical addresses had 20 bits). Therefore if you interpret addresses as signed values, you could say that the natural base of 8086 memory is -16. Of course the 8086 also expects the address 00000 to be available, because it puts the interrupt table there. Moreover, in the original IBM PC, you were guaranteed to have ROM starting from F0000 through FFFFF is available as ROM and from 00000 to 7FFFF is available as RAM; memory above that may or may not exist. Note that this is a continuous area if you consider address wrap-around. Therefore you could also say the original IBM PC had a natural base of -65536.

Of course that neglects the video memory mapped in a region which may or may not be adjacent to existing RAM and/or ROM memory addresses. So the total memory is in general not even contiguous. And even if it is, the address 0 is not special in any case.

Moreover, if you don't look at the real memory, but at the virtual memory in modern CPUs/operating systems, you'll find that address 0 (more exactly, the memory page 0; on x86 that's the address range from 0 to FFF) is typically not mapped (so that null pointer dereferences are caught by the hardware). Therefore you might also claim that virtual memory is a 4096-based array, because that's the first virtual address which actually corresponds to existing memory. Which of course assumes that virtual memory is assigned as a single block; this assumption may well be violated if your program uses shared memory and/or memory-mapped files.

To summarize: There's nothing special to the memory address 0 which would make it the natural "begin" of memory, and there's no guarantee that memory is contiguous (which arrays per definition are), and this applies both to physical and to virtual memory. Therefore (a) the interpretation of memory as an array is not a perfect match, and (b) even if you do so, there's absolutely no reason to assume it is 0-based.

Re:We don't

[vux984]

Wow.

For example, the 8086 expects to be able to read instructions starting at address FFFF0 (note that 8086 physical addresses had 20 bits). Therefore if you interpret addresses as signed values, you could say that the natural base of 8086 memory is -16.

That's the reset vector, and its not the 'first address' it can read, its simply the address it reads from by default after a reset.

Therefore you could also say the original IBM PC had a natural base of -65536.

Yes, clearly that would be the most natural way of interpreting that... no. wait. That would be a pointlessly convoluted way of interpreting it. Ditto for treating FFFF0 as -16, which is just plain silly because its probably more accurate to write it as FFFF:0000. That would be address 0, in segment FFFF.

Of course that neglects the video memory mapped in a region

Sorry. No. That all happens on top of the physical address space. Think about the RAM or ROMs, not the more complicated stuff layered on top of them.

Therefore (a) the interpretation of memory as an array is not a perfect match,

A stick of RAM as an array of cells is really about as perfect as it gets.

and (b) even if you do so, there's absolutely no reason to assume it is 0-based.

How are the physical addresses in a DRAM chip numbered? (and what signals would you need to put on the wire to read or write to the cell? )

That's right, they start at 0, always. Whether its a 128 byte rom from 1976 to a 4GB DDR3-DRAM from 2013.

And the why? Goes down to how you signal on the wire itself. If you have 4 wires to use for the address line, then 0,0,0,0 is the first address, 0001 the second, and so forth.

And really, I'm sure you already know this.

Re:We don't

[maxwell demon]

For example, the 8086 expects to be able to read instructions starting at address FFFF0 (note that 8086 physical addresses had 20 bits). Therefore if you interpret addresses as signed values, you could say that the natural base of 8086 memory is -16.

That's the reset vector, and its not the 'first address' it can read, its simply the address it reads from by default after a reset.

Are you intentionally misinterpreting what I wrote? This address is the temporally very first address the processor reads, and therefore the processor assumes that there's something to read starting at that address because otherwise it could not work. And due to the way the hardware wrks, this means that all of F0000 to FFFFF is available. Which, due to 20 bit addressing and wrap-around is directly followed by the address 0.

Therefore you could also say the original IBM PC had a natural base of -65536.

Yes, clearly that would be the most natural way of interpreting that... no. wait. That would be a pointlessly convoluted way of interpreting it. Ditto for treating FFFF0 as -16, which is just plain silly because its probably more accurate to write it as FFFF:0000. That would be address 0, in segment FFFF.

Sorry, but that address I was speaking about at that point (first address of BIOS ROM in the original IBM PC) is definitely not represented by FFFF:0000. Anyway, the address represented by FFFF:0000 can as well be represented as F000:FFF0. Or as FF00:0F00. Or as FF80:07F0. Or as F123:EDC0. Or ...

Anyway, this segmentation is a speciality of the 8086; it is in no way natural, but was done mostly to provide the possibility of automatic code translation from the earlier 8080.

Of course that neglects the video memory mapped in a region

Sorry. No. That all happens on top of the physical address space. Think about the RAM or ROMs, not the more complicated stuff layered on top of them.

In the original PC, this happened at the hardware level. For the CPU, there was no difference between normal RAM and video RAM. I don't know how it is in more modern computers, but I guess it gets still mapped at hardware level for efficiency reason.

But anyway, even if you don't consider video memory, the point remains that if you consider the memory as starting at 0, there was generally a gap between the last RAM address and the first ROM address.

Therefore (a) the interpretation of memory as an array is not a perfect match,

A stick of RAM as an array of cells is really about as perfect as it gets.

The processor doesn't address a stick of RAM (you don't have instructions to read cell X from stick Y). The fact that your memory is organized in sticks is just as irrelevant for the programming model as the fact that it is made of semiconductors, and that the electrons are ultimately described by quantum mechanics. Anyway, even on that lever, you're wrong.

and (b) even if you do so, there's absolutely no reason to assume it is 0-based.

How are the physical addresses in a DRAM chip numbered? (and what signals would you need to put on the wire to read or write to the cell? )

If you go to a single stick of RAM, you'll find that for any address there is a corresponding memory cell. Which one is the first is therefore simply a question of declaration, not a question of naturalness. Indeed, if you look at early memory chips without all the modern optimizations, you'll see that if you exchange two address lines on the chip it won't really matter, because while it will read a different physical memory cell, it will do so consistently. Which demonstrates that at this level the address isn't even a number, but just a bit pattern.

That's right, they start at 0, always. Whether its a 128 byte rom from 197

Re:We don't

[vux984]

Which, due to 20 bit addressing and wrap-around is directly followed by the address 0.

So you agree there's an address 0? The rest is just a lot of handwaving to try and avoid admitting that its counting from zero.

Sorry, but that address I was speaking about at that point (first address of BIOS ROM in the original IBM PC) is definitely not represented by FFFF:0000.

The reset vector for the 8086 processor is at address FFFF0h (16 bytes below 1 MB). The value of the CS register at reset is FFFFh and the value of the IP register at reset is 0000h to form the segmented address FFFFh:0000h, which maps to physical address FFFF0h.

Anyway, this segmentation is a speciality of the 8086; it is in no way natural

Its somewhat clumsy, but there is nothing unnatural about the actual numbering itself. the segment and offset overlap in a very simple logical way.

If you go to a single stick of RAM, you'll find that for any address there is a corresponding memory cell. Which one is the first is therefore simply a question of declaration, not a question of naturalness. Indeed, if you look at early memory chips without all the modern optimizations, you'll see that if you exchange two address lines on the chip it won't really matter, because while it will read a different physical memory cell, it will do so consistently. Which demonstrates that at this level the address isn't even a number, but just a bit pattern.

Semantics.

If I draw a 4 x 4 grid, and label the cells 0 to 15 on a transparecy, and then rotate the transparency 90 degrees the cells are still numbered 0 to 15. That doesn't number them 1 to 16.

That's all switching address lines around does; swaps rows and columns around. They're still numbered from 0 to n.

No. 0,0,0,0 is one address, and 0,0,0,1 is another address. Also, why do you consider 0,0,0,1 the second address, and not e.g. 1,0,0,0?

As if you don't know the answer:

0000 = 0
0001 = 1
0010 = 2
0011 = 3

That's not blind luck. Hardware is designed that way. We don't have to declaratively "assign" the cells ordinal numbers as its an inherent property of the design. Whatever is 0000 is logical 0. Whatever is 0001 is logical 1. Whatever cell 1111 wired to is logical 15.

As to why I consider 0 first, then 1, and all the way 15 last? That is the natural ordering.

Plus as you know by treating the address lines as a binary representation of the address, we also benefit from being able to do things like address arithmetic and binary shifting, directly against the address encoding and have it have meaningful semantics.

After all, all I did here was to write down the bits in a different order.

you mean like "LTROL" ?

Re:We don't

[maxwell demon]

Which, due to 20 bit addressing and wrap-around is directly followed by the address 0.

So you agree there's an address 0? The rest is just a lot of handwaving to try and avoid admitting that its counting from zero.

From the processor's view (which has arithmetic operations, and therefore a natural interpretation of binary patterns as numbers), there is indeed an address 0. I never denied that. But that does not imply that the memory is naturally(!) a zero-based array. First, the (-128)-based array of 256 elements has also an element with index 0. Thus you cannot imply from the existence of an element 0, that there is an element 0. Second, as I already explained several times, there may (and in general will) be holes in the range of existing memory, making the 0-based array model of memory not an exact fit.

To avoid holes in memory you then tried to turn to single memory bars, which are not only completely irrelevant as far as the programming model goes, but at which level the address is no longer naturally a number. You can somewhat recover a numeric value if you look at the physical design of a memory chip, except that it consists of a two-dimensional array of memory cells, so the address from that view is not one number, but two. And if you look at the complete memory bar, then some of the address lines will be used for chip selection, so you'll get three numbers. That is, even then at the chip level you don't really have an address 0, but at best an address (0,0,0) (and that's assuming that the bits are addressing the lines/columns/chips in order, which may not actually be true).

The reset vector for the 8086 processor is at address FFFF0h (16 bytes below 1 MB).

Yes. But (and I put it in bold because copy repeatedly ignored that fact, despite me repeatedly telling you): At that point I was no longer speaking about the reset vector. Maybe you get back to my original post and actually read it. Here's a hint for you: Context matters.

Its somewhat clumsy, but there is nothing unnatural about the actual numbering itself. the segment and offset overlap in a very simple logical way.

Logical != natural.

As if you don't know the answer:

0000 = 0
0001 = 1
0010 = 2
0011 = 3

Only if you interpret them as binary numbers. Which in the memory hardware isn't natural. Rather, each bit by itself gives a two-way selection of different subsets of memory cells.

Whatever cell 1111 wired to is logical 15.

Anfd here you're even wrong as far as the processor goes (well, assuming a full value, of course). An all-1 can as well be interpreted as -1. The processor has instructions for both interpretations.

Re:We don't

[maxwell demon]

Oops, "Thus you cannot imply from the existence of an element 0, that there is an element 0." is of course nonsense. It should read "Thus you cannot imply from the existence of an element 0, that the first element is element 0."

Re:We don't

[K. S. Kyosuke]

Huh? CTSS is a time sharing system! Of course you're sharing the core.

Well, depends on your point of view. I believe that CTSS was swapping whole cores when doing the VM switch, so you're sharing the HW but not even the physical address space - there was only one user program running in the B-core at any given instant. Each of the time-sharing users was provided with an illusion of a whole physical machine, much like with VM/CMS.

Re:We don't

[vux984]

It should read "Thus you cannot imply from the existence of an element 0, that the first element is element 0.

  The enumeration of memory cells by the pattern of bits that accesses them is the most natural way to enumerate them.

The lowest element is the first element in any natural ordering of things.

Its an arbitrary assignment, but its the most natural arbitrary assignment possible.

2s complement interpretations of the address lines, or mathematical overflow/underflow is all valid, but is a more complex interpretation. And no normal human being would ever default to using 4 bit to enumerate objects from -8 to 7.

Re:We don't

[Eunuchswear]

Reading comprehension fail. Mark Hoyle isn't Martin Richards.

Re:We don't

[Eunuchswear]

Huh? CTSS is a time sharing system! Of course you're sharing the core.

Well, depends on your point of view. I believe that CTSS was swapping whole cores when doing the VM switch, so you're sharing the HW but not even the physical address space - there was only one user program running in the B-core at any given instant. Each of the time-sharing users was provided with an illusion of a whole physical machine, much like with VM/CMS.

From http://www.multicians.org/thvv/compatible-time-sharing-system.pdf

7094 CPU Modifications. The hardware RPQs that made CTSS run on MIT’s 7094s
added an interval timer (B/M 570220) and memory boundary and relocation registers
(RPQ E007291) to the 7094 processor.

[...]

Memory Boundaries and Swapping. CTSS used the modified 7094’s memory boundary
register to limit user jobs’ access to only part of B-core, so that the supervisor didn’t have
to swap 32K to the drum for every job.

Nope, sounds like it could have multiple jobs in core.

Re:We don't

[K. S. Kyosuke]

It could have (inaccessible) fragments of data of other processes in the core but not multiple running jobs as such. That's at least what the CTSS Programming Guide told me. I said "there was only one user program *running* in the B-core at any given instant", and that is technically correct - the best kind of correct. :]

Re:We don't

[Eunuchswear]

I said "there was only one user program *running* in the B-core at any given instant", and that is technically correct - the best kind of correct. :]

True of all uniprocessor systems, including, for example, Linux unprocessor systems.

Re:We don't

[K. S. Kyosuke]

Linux uniprocessor systems generally don't page out processes unless they have to. CTSS *always* swapped out processes because there was no virtual address space - the data had to be physically moved for the process to see it where it expected it.

Re:We don't

[Eunuchswear]

Linux uniprocessor systems generally don't page out processes unless they have to. CTSS *always* swapped out processes because there was no virtual address space - the data had to be physically moved for the process to see it where it expected it.

Then what purpose did the base/limit registers serve?

I'd contend that a system with base/limit registers does have virtual memory - the addresses manipulated by user programs are not physical addreses.

base/limit is a degenerate case of segmentation, a machine where the user program sees one segment.

Memory Boundaries and Swapping. CTSS used the modified 7094’s memory boundary
register to limit user jobs’ access to only part of B-core, so that the supervisor didn’t have
to swap 32K to the drum for every job.

Re:We don't

[maxwell demon]

No, the most natural assignment is to not assign anything at all, but to take the bit pattern as what it is: A bit pattern.

Re:We don't

[maxwell demon]

When adding, the processor set a bunch of flags, some of which (like carry) only make sense when interpreting as unsigned values, others (like sign or overflow) only make sense when interpreting as signed values. Therefore it is wrong to say that the processor only interprets the numbers as unsigned. Anyway, even if there's no difference, it is nonsense to single one of them out and claim that the processor uses that. If both are indistinguishable, then the processor obviously doesn't distinguish between them.

But then, addition/subtraction is special in that regard. You already mentioned one example, arithmetic shift. Other examples are multiplication and division instructions. And yes, of course they are separate instructions, just as in signed magnitude implementations you need separate instructions for signed and unsigned addition, because they simply have separate results. But that there are instructions for both means that the processor does not single one out as the "correct" one. A processor which had only instructions (and flags) for one of the interpretations could be said to do that.

(BTW, it's two's complement, not two's compliment; it's not about telling people nice things about them).

Re:We don't

[vux984]

No, the most natural assignment is to not assign anything at all, but to take the bit pattern as what it is: A bit pattern.

You know of many computers that need to put the bit pattern 'address' of the memory cell containing the next cpu instruction to run, for each instruction?

Because without an ordinal assignment, there is no concept of "next", and the CPU has no way to "advance", no way to jump relative. Every single instruction would need the bit pattern of the next cell to load and execute.

Or we could assign an ordinal number to each cell in some logical natural way... gee I wonder what we'll come up with...

Re:We don't

[maxwell demon]

We were discussing memory chips (on your initiative, after I've argued that from the processor's view the memory cannot be seen as an array due to the memory holes). Memory chips don't have an idea about the processor's inner working. That from the processor's view the addresses indeed are numbers I never denied (read up the previous discussion again).

Fortran

[Roger W Moore]

Why do programmers start counting at zero?

I expect that this is going to annoy a lot of Fortran "programmers".

Re:Fortran

[TheRealMindChild]

VB programmers

Sesame Street: Feist sings 1,2,3,4

[theodp]

Sesame Street: Feist sings 1,2,3,4. Not 0,1,2,3. :-)

Re:Sesame Street: Feist sings 1,2,3,4

[Niterios]

As you can see, the count does not count his virginity. http://www.youtube.com/watch?v=B-Wd-Q3F8KM

10 million?

[sootman]

So, is that (dec) ten million kids or (dec) two million?

Re:10 million?

[transporter_ii]

Dude, you have to start at 0, so it is 9,999,999 kids.

Re:10 million?

[Dabido]

You have a 01 in 10 chance of guessing!

Copyrights!

[sootman]

Careful there, Z -- that might count as a "public performance" of Happy Birthday. I know you're rich, but the payment for and audience of 10 million might be kinda high.

Re:Copyrights!

[Vintermann]

Not to mention if it's in a loop. Good lord, Zuckerberg could go broke!

Re:Copyrights!

[multimediavt]

Careful there, Z -- that might count as a "public performance" of Happy Birthday. I know you're rich, but the payment for and audience of 10 million might be kinda high.

My first thought, exactly. I really hope he got the rights secured or he might get sued for everything he's worth. Those sisters are vicious about protecting their copyright. I would have picked Row, Row, Row Your Boat before Happy Birthday. Way to teach children how to respect copyright Zuck and Bill!

Re:Copyrights!

[romiz]

The usual loop song is 99 bootles of beer.

It's not a count, it's an offset

[Andover Chick]

It is an indicator of a shift off the first position.

Confusion of terms

[advid.net]

Numbering items with an index starting from zero isn't counting. It's just numbering.

Teach this first, along with counting continguous elements by index substraction + 1.

Re:Why do programmers start counting at zero?

[CubicleZombie]

It's a "C" thing. Try Pascal or other Wirth family languages instead if you want to start at 1.

Or .NET.

Maybe.

Counting versus Indexing

[Millennium]

Programmers don't count starting at zero. They index items in collections starting at zero, because it makes certain actions more convenient when you're working at a very low level. But when it comes time to count the items, they start at 1 like everyone else.

Re:Counting versus Indexing

[Anonymous Coward]

Depends if you start counting before you see the first element or not. If I need to count the beans in an empty jar, I would start from 0. In fact, every sane counter is initialized with 0.

I think the old-schoolers here still have to understand the meaning of the cardinal number zero.

But no, preschoolers don't have to worry about that.

Re:Why do programmers start counting at zero?

[Anonymous Coward]

Actually, in Pascal you can start your index whereever you want. For example, the following defined an array starting at 42:

var a: array[42..99] of integer;

Re:So is it...

[theodp]

10 million, but your point is well-taken - you'd refer to the ten millionth kid as 9,999,999!

0 Happy Birthday to You

[Anonymous Coward]

1 The RIAA Will Sue
2 Happy Birthday to Marky
3 Our Lawyers'll be Contacting You

Re:0 Happy Birthday to You

[mrego]

Maybe Zuckerberg will buy Warner's copyright (which supposedly goes until 2030) and give the song away to the US for free. Otherwise he can pay the royalties.

Re:0 Happy Birthday to You

[PPH]

The reason nobody sang 'Happy zeroth birthday' to me was that my mom was in no mood to sing at the time.

A Good Use of His Time?

[bobwalt]

Perhaps his time would be better spent getting Facebook to work correctly or maybe its just that his method of counting doesn't work that well.

Re:Why do programmers start counting at zero?

[Ihlosi]

It's a "C" thing

No, it's actually an assembly language thing, where you access array elements by base address and offset. Your first element sits at offset zero. C is merely a wrapper for assembly that's suffering from various wardrobe malfunctions.

No zero

[Anonymous Coward]

Personally, I am sick and tired of seeing Microwaves that treat zero like it's a counting number. When it reaches zero it's supposed to stop, but instead they often continue for an additional second.

Youtube does the same thing. Advertisements on videos with that little countdown button. It says it delays 5 seconds, but it actually delays 6, because once it reaches zero, it waits for another second before ending.

This is grade school math folks. Zero is NOT a counting number. It's the FIRST (1) combination of a bit pattern.

So for any of you programmers out there that have been using zero in this way... STOP. It's sloppy programming, and I wouldn't hire you.

Re:No zero

[sgbett]

When you put in 1 minute, the instant you press start it likely goes to 0:59, which is a property of the display.

If you could see ms you would see those counting down.

So you are still nuking your food for exactly a minute, just that the time remaining is always truncated.

Re:No zero

[u38cg]

Truly, a life spent focusing on the fundamentally important.

Re:No zero

[Duhavid]

If that is true, then you will see zero on the display for a minute or so.

Re:No zero

[sgbett]

if you microwave only shows minutes, then yes they would. I think most show seconds though?

Re:No zero

[Duhavid]

Mine shows decades.

Good point.

Never post tired from a release.

Good Luck

[puddingebola]

I'd like to wish Mark Zuckerberg luck in his new teaching career. He'd better start now, it will take him most of his natural life to make a dent in that number.

Make women *what* you?

[JamieKitson]

Are those YouTube features personally tailored?

Also I'm pretty sure that theodp is breaking the Flickr T&Cs by linking directly to the image.

Re:Why do programmers start counting at zero?

[larry bagina]

It's a computer thing. (What is C if not a portable PDP 11 assembler?)

Counting is an algorithm

[swm]

Counting is an algorithm, like long division or the use of logarithmic tables--in this case an algorithm for assessing the exact numerosity of a set of objects. It consists of reciting a memorized stretch of blank verse ("one, two, three, four, five, ...") while uniquely pairing each foot in the poem with an object in the spotlight of attention, without skipping an object or landing on one twice. Then, when no object remains unnoticed, you announce the last foot you arrived at in the poem as the numerosity of the set.

This is just one of many possible algorithms for ascertaining numerosity. In some societies, people pair up the objects with parts of their body, and I know several computer programmers who count like this: "Zero, one, two three, four. There are five."

--Steven Pinker, The Stuff of Thought, p. 141

Re:Counting is an algorithm

[Joining Yet Again]

Now try formalising that without begging the question.

Re: Counting is an algorithm

[turbidostato]

Add 0 to the well-ordered set and change the algorithm so you start taking out elements from the sorted set. This way you naturally include the empty set and you tag the algorithm (retiring the zero means "hey, I start counting)

Re: Counting is an algorithm

[maxwell demon]

Add 0 to the well-ordered set and change the algorithm so you start taking out elements from the sorted set. This way you naturally include the empty set and you tag the algorithm (retiring the zero means "hey, I start counting)

That's a very unnatural way of including zero. Versus the natural way outlined in the last paragraph of the parent.

We should

[trinaryai]

The biggest mistake in teaching mathematics is learning to start counting at one. That's fine if the only math ever learned is basic arithmetic; but higher order concepts including fractions, algebra, and number sets beyond whole numbers become much more difficult as a result. Why do we start counting at zero? Because zero is "Origin". When we count, what we are actually doing is this: I have zero. Adding one, I have one. Adding one, I have two. Adding one, I have three. Etc. By using zero as our origin, we can teach arithmetic using the integer set, rather than the whole number set. We can teach that the minus sign just means a change of direction, and that addition and subtraction are actually the same thing. So addition/subtraction is nothing more than repeated counting - a shortcut. Multiplication and division are repeated addition. Fractions are just another way of expressing division. Exponents/roots are repeated multiplication. "If you can count, you can do math. Everything else is a shortcut." Counting from zero allows us to teach euclidean coordinates / geometry as an extension of what students already are familiar with, rather than something new. Why do we start counting at zero? Because zero is "Origin".

Re:We should

[Warbothong]

By using zero as our origin, we can teach arithmetic using the integer set, rather than the whole number set.

Why would that be a good thing? The Naturals (including 0) can be associated with real, tangible things ("I have 0 apples", "I have 1 apple", etc.), whereas the Integers are a clever hack to make subtraction a closed operation by inventing non-physical 'negative numbers'. I think this is

We can teach that the minus sign just means a change of direction, and that addition and subtraction are actually the same thing. So addition/subtraction is nothing more than repeated counting - a shortcut.

The idea of a number line (ordinals) is quite abstract. Young children understand numbers more in terms of sizes (cardinals), eg. "this bag contains 3 apples". In this context addition and subtraction are not quite the same, since subtraction may not be defined: if I have 2 apples and you take 3 apples from me, how many apples do I have?

Rather than introducing a new, unphysical model of numbers, we can treat subtraction as a relation; "3 - 2 = 1" means that "1 + 2 = 3" (since, in general, for all Naturals x, y and z: x - y = z implies z + y = x). In the context of programming, this would be like Prolog.

Multiplication and division are repeated addition. Fractions are just another way of expressing division. Exponents/roots are repeated multiplication.

.

Multiplication is indeed analogous to addition, but division is analogous to subtraction and hence it is also difficult to think of in terms of an operation (think: remainders). Fractions (ie. Rationals) are to division as Integers are to subtraction, ie. a closed set (except for division by 0). Useful to teach, but only as an interesting hack once multiplication and division are grasped for the Naturals. One thing I never understood about teaching fractions is the insistence on converting them to Naturals, Integers, etc. and decimal representations. Fractions are a beautiful expression of numbers, but in school they were always treated as problems which need to be 'simplified' into some obscure series of decimals.

Counting from zero allows us to teach euclidean coordinates / geometry as an extension of what students already are familiar with, rather than something new. Why do we start counting at zero? Because zero is "Origin".

Euclid didn't use coordinates; he used pure geometry, ie. points, lines, arcs, right-angles, etc. Coordinates, as a simple relationship between goemetry and algebra is attributed to Decartes (ie. Cartesian coordinates). Geometry is useful without coordinates, and arguably it is easier to grasp without them. For example, proofs of Pythagoras's theorem which cut up and rearrange shapes are more intuitive than ones that rearrange formulas.

That "birthday loop" has the wrong upper end

[Anonymous Coward]

If you are going to teach idiomatic loops, do it correctly. It's not

for (i=0; i<=3; i++)

but

for (i=0; i<4; i++)

Note that in the second, idiomatic version your actual number of lines appears.

Note also that the two conventions are strongly related.

Re:That "birthday loop" has the wrong upper end

[maxwell demon]

Do you know what "idiomatic" means?

Re:Why do programmers start counting at zero?

[MtHuurne]

I recommend indexing from 0 and using exclusive upper bounds in all languages. The number of off-by-one errors decreases dramatically in my experience.

What 0-based and 1-based counts mean

[tepples]

4 lines of lyrics from Happy Birthday to You

Others beat me to the copyright jokes.

But seriously, both 0-based and 1-based counting have valid, physical meanings. A 0-based count measures the number of valid elements before this one is processed. This count of preceding elements is useful for indexing in the majority of popular programming languages. A 1-based count, on the other hand, measures the number of valid elements after this one is processed. One often needs to allocate memory for elements in a manner such that the amount of memory used at once matches a 1-based count.

The Article Is Self-Contradicting

[StormReaver]

I started reading the article linked to in, "start counting at zero", and stopped halfway through. I feel sorry for anyone who reads that article, but isn't a programmer (hell, even if they are programmers), as it is self-contradictory crap:

From the article:

Itâ(TM)s not about [pointer math] because pointers and structs didnâ(TM)t exist....So I found [the person who originally decided to start array indices at zero] and asked him [why he started array indices at zero].

Then the father of zero-index arrays said:

...if p is a pointer p+1 is a pointer to the next word after the one p points to.

He then goes on to admit that zero-index arrays are the most efficient means of calculating memory addresses, and brushes aside his self-contradictions by saying that the "why" is more important than the "how".

Which means, as should be obvious to everyone, that zero indices are the most natural way to express pointer arithmetic; internally to your language runtime if your language doesn't support pointers, or externally if pointers are programmer-facing.

The author of this article needs to brush up on computer fundamentals before self-publishing his absurd opinion pieces on computer fundamentals. Zero-index arrays are "conventional programming wisdom" because they have always been the easiest way to calculate memory addresses.

Re:The Article Is Self-Contradicting

[ccanucs]

Not to mention, that self-modifying assembly code needs to know where it is right now (0-base) and how many bytes further on to write the new instructions. The pointer arithmetic there has nothing to do with arrays but the exact same principle applies.

Counting From Zero Actually Makes more Sense

[physicsphairy]

Even well into adulthood, people are still confused by, e.g., the difference between "the early 1700s" and "the early 17th century" (which is actually the 1600s). Turns out, whether you like it or not, the first place value of 10^2, 10^3, 10^4, etc. you count through is always the 0th one. It's only in the very specific circumstance of counting the 10^1 place and when all the other 10^x place values are zero that the 0 gets skipped. Why not be consistent?

Besides being more consistent, I also think it is more intuitive (barring the fact that we are culturally inducted into thinking that it isn't). If you were counting *backwards,* say, starting with ten cookies and removing one cookie off a plate each time, it would be perfectly intuitive to you that you should count down to zero cookies, taking the very last cookie off the plate. The zero cookie limit is enforced by physical reality, while the one cookie limit is enforced by your arbitrary decision to interrupt your process of removing cookies and leave one cookie on the plate. Likewise, in the reverse process, you should also start your counting at an empty plate.

Re:Counting From Zero Actually Makes more Sense

[T.E.D.]

Yes, but it that case, we should all be using base 11 for our human numbering system (with our 10 fingers we can count from 0 to 10.) Or perhaps base 6, and use the second hand as the 6^1 digit.

I'll tell you what. You start off with base-11/base-6 numbering and math, and get back to the rest of us when you can honestly report how much better that is working for you.

Re:Counting From Zero Actually Makes more Sense

[platypusfriend]

Well, since we (as humans) tend not to converse in math, why don't you explain it in English? I agree that explaining it in math would probably be wasting your time.

Re:Counting From Zero Actually Makes more Sense

[Bite The Pillow]

Zero is not a counter, it is a placeholder meaning no things to count. It was not even a concept in early number systems.
Count cookies. Do you close your eyes and say "zero cookies" before moving to the first? No, because that's stupid.
Remove cookies, does anyone really enumerate zero after the last cookie is gone? No. 2, 1, none.
If you enumerate with zero, it is far more intuitive to count
2 cookies
1 cookies
0 cookies, zebras, Mexicans, herpes, doors, suns, darts

Because there is nothing left to say what you are counting. There are zero of all of those, and more. Start with apples and oranges, remove oranges. At the end do you have 0 oranges? No, you have a number of apples.

Conceptual thinking does not apply to counting. We should not force it to so that programming makes sense.

Re:Counting From Zero Actually Makes more Sense

[Zalbik]

Flunked math didn't you? As a mathematician I won't even respond to your 'points' since you are posting gibberish.

Flunked kindergarten, didn't you? You know, the part about working and playing well with others.

As a person, I won't even respond to your "points" since:
a) You don't appear to have one
and
b) You're an asshole.

Please, stay off the interwebs. We're all full up on jerks here.

Re:Counting From Zero Actually Makes more Sense

[cellocgw]

Well, since we (as humans) tend not to converse in math, why don't you explain it in English?

Actually, since this is /., someone needs to post a car analogy.

Re:Counting From Zero Actually Makes more Sense

[HyperQuantum]

Actually, people count from zero without realizing it, in my opinion. See how they count:

1, 2, 3, 4, ...

Each number actually represents a change of state. The initial state is zero. When people say "1", it means they change state from zero to one. So they actually count from zero.

Simple

[bickerdyke]

Because you have to start counting SOMEWHERE.

Re:Why do programmers start counting at zero?

[martijn hoekstra]

Last I checked .NET isn't a language.

Re:They don't. - They really don't.

[Jane Q. Public]

We don't start counting at 0. Our compilers do.

Simple: Because computers do.

[VortexCortex]

Comparing against zero is fast. Yes, even in high level languages like JavaScript if you write your loop in reverse it goes faster because your compare will be against zero instead of some in-memory or register value. Do some assembly level programming. At that level it's blatantly, smacked in the face, obvious.

Re:Simple: Because computers do.

[BitZtream]

That hasn't been true for 30 freaking years. Stop repeating crap your tired old, hasn't worked with a real computer in the past 2 decades, crap professor spewed at you.

What processor takes more than 1 cycle to test a value other than 0? Educate me, please.

Re:Simple: Because computers do.

[JesseMcDonald]

What processor takes more than 1 cycle to test a value other than 0? Educate me, please.

You can often do away with the extra test altogether when you're comparing against zero, provided the decrement operation sets the condition bits. It's also fairly common to have dedicated counters and "decrement and branch if not zero" opcodes. If you're comparing against a non-zero constant, and the compiler doesn't optimize the comparison away, that's at least one extra instruction and one extra cycle in the body of the loop. In optimized code the space required for the extra opcode can be just as important as the time to perform the extra arithmetic.

Counting up from 0 to 99 in PowerPC assembly:

li r3, 0
loop:
...
addi r3,r3,1
cmplwi r3,100
bne loop

Counting down from 100 to 1:

li r3, 100
loop:
...
addi. r3, r3, -1
bne loop

or even

li r3, 100
mtctr r3
loop:
...
bdnz loop

Re:Simple: Because computers do.

[FireFury03]

Comparing against zero is fast. Yes, even in high level languages like JavaScript if you write your loop in reverse it goes faster because your compare will be against zero instead of some in-memory or register value. Do some assembly level programming. At that level it's blatantly, smacked in the face, obvious.

Conversely, in some conditions, iterating through data in reverse order is much slower due to the way data is frequently prefetched into caches. For example, if you request a byte from a storage medium, the OS may choose to fetch and cache several bytes following it, on the assumption that you will probably iterate through those next. If you go backwards then this prefetch logic doesn't work and you're forever fetching data from the media instead of being able to pull much of it from the cache.

Re:Simple: Because computers do.

[Alioth]

Nope, it's still absolutely true today. We are still using x86 and other architectures that fundamentally control loops by setting a flag somewhere and using a conditional branch. All variants of x86 (basically, anything where arithmetic instructions set flags) can do the loop control in one fewer instructions if the loop is comparing by zero instead of an arbitrary value. Basically, in a loop testing for an arbitrary non-zero value in many architectures in use today will be something like (in pseudocode):

inc register
cmp #value
bne loop

Now counting down it'll be more like:

dec register
bne loop ...because when the dec instruction on these architectures results in zero being stored in the register, it sets the zero flag. If counting up to an arbitrary value you need that extra compare instruction to do that job.

Re:Why do programmers start counting at zero?

[T.E.D.]

It's a "C" thing. Try Pascal or other Wirth family languages instead if you want to start at 1.

...or pretty much any language that didn't crib its syntax from C.

Thinking that counting from 0 is a programming thing is a sure indication of a person with a very narrow experience with programming languages. The most programmer-abusive set of them at that.

Re:Why do programmers start counting at zero?

[pr0fessor]

.Net is 0

If you don't start with zero it won't make sense

[Xiver]

00.01.02.03.04.05.06.07.08.09
10.11.12.13.14.15.16.17.18.19
20.21.22.23.24.25.26.27.28.29
30.31.32.33.34.35.36.37.38.39
...
0000 0001
0010 0011
0100 0101
0110 0111
1000 1001
1010 1011
1100 1101
1110 1111
...

Re:Why do programmers start counting at zero?

[T.E.D.]

No, its not "a computer thing" computers don't "count". They increment binary numbers. They don't have arrays; they have RAM and indexing features.

Nearly all programmers don't interface directly with computers, they use programming languages. How programming languages index their arrays is entirely up to the programming language designers. Different ones do it differently. C's designers chose to do it in a way that allowed their compiler writers to do as little work as possible (which is how they made most every language decision). C became popular, so a lot of languages copied it. But a lot more did not. (Ada for example allows the user to pick their own array indices for their own convenience, rather than the compiler writer's.)

Don't confuse historical accidents with holy writ.

Re:Zero is a special case

[Joining Yet Again]

Your whole post is very time-cuboid, but I especifically got brainfucked by:

'empty' (a form of zero)

This is the kind of crap that comes from programmers trying to think in the machine domain rather than the problem domain, which in turn comes from fucked up hybrid languages like C++.

(I mean, I'd accept the excuse, "C++ gives you high level tools but is also close enough to the machine to allow efficient programming," if anyone actually programmed efficiently these days. But increase in software complexity should NOT require me to have two orders of magnitude clock speed increase.)

Re:Why do programmers start counting at zero?

[CubicleZombie]

In the mish mash of legacy components wrapped up in the .NET architecture and the various third party components in frequent usage, I've run into all kinds of things indexed at 1. Thus the 'maybe'.

I disagree

[wcrowe]

I think introducing zero-based counting to older children is a good idea. For younger children, this is a mistake.

"You have ten fingers Zoe."

"No I don't. I have nine. See? 0,1,2,3,4,5,6,7,8,9 -- 9!"

Teaching young children zero-based counting, before they can count is like teaching them the Greek alphabet before they learn their ABCs.

Re:I disagree

[Anonymous Coward]

That's probably useful if they are Greek though.

Re:I disagree

[maxwell demon]

What's confusing is teaching them digits, but introducing zero as a modifier of one in the number 10 instead of as a digit itself.

Does anyone really teach such nonsense? (To avoid misunderstandings: The "0 as modifier" is the nonsense.)

0 based counting?

[Dcnjoe60]

I've heard of 1 based counting (0,1,2,3,4, etc)
I've heard of 2 based counting (0,2,4,6,8, etc)
I've heard of 5 and 10 based counting (0,5,10,15, etc. or 0,10, 20, 30, etc.)
and so on,
but wouldn't 0 based counting just give you 0,0,0,0,0?

He's wrong about BCPL

[Chrisq]

From TFA:

and though BCPL arrays are zero-origin, the language doesn’t support pointer arithmetic, much less data structures

In BCPL the only way of addressing arrays is by pointers. Pointers are fundamental. Variables can contain pointers to data (vectors), procedures, vectors of procedures etc. If you see that the only way of making structures is to use vectors and pointers you see that zero-indexing is fundamental.

Zero it out!

[Impy the Impiuos Imp]

> Repeat Loops includes an out-of-place JavaScript example that shows kids it's as
> easy as 0-1-2-3 to generate 4 lines of lyrics fromHappy Birthday to Youbyusing zero

Happy Birthday is copyrighted, so you better get permission or you'll get a good education on numbers with lots of zeroes.

Yeah, but you're ruining a traditional joke

[Medievalist]

Why do programmers start counting at zero?

We don't. We start indexing at zero (in some languages), because that's usually the offset of the first useful location in an array (ie, addr + 0).

Yeah, yeah, yeah, and testing against zero is usually computationally cheaper in hardware. You're right, but you're wrecking an ancient jest.

Female programmers can only count to nine without taking their shoes off, but male programmers can count to ten by just unzipping.

That chestnut's as traditional as "why do programmers always get Hallowe'en and Christmas mixed up", you know? Have some respect for the history!

Re:Yeah, but you're ruining a traditional joke

[BitZtream]

Yeah, yeah, yeah, and testing against zero is usually computationally cheaper in hardware.

No, it doesn't. Just some shitty hardware implementations for eons ago took longer to say none 0 for some pretty stupid fucking reasons.

Its not 1970 anymore.

Re:Yeah, but you're ruining a traditional joke

[fisted]

Of course it is, why would you claim such nonsense? Are you deducing that from your web-development experience?

Testing against a number typically involves a subtraction, and the result being tested ... wait for it .... against zero. Testing against zero is directly supported (and, for instance on the AVR architecture, takes a single clock cycle. on x86 it probably takes 7 1/3 ;))

Re:Yeah, but you're ruining a traditional joke

[Alioth]

Speak for yourself. I can count to 1023 without taking off my shoes or unzipping...

Re:Yeah, but you're ruining a traditional joke

[maxwell demon]

If all you want to do is to test for equal/not equal, you don't need a subtraction. You can just do a bitwise comparison.

Of course the way you'd do it in hardware is to xor the corresponding bits and test the result against zero, so at the fundamental level you're right. But the circuit is so simple that I'd expect it to still finish in one cycle, so a processor implementing that would not necessarily be slower in comparing a value to zero than in comparing two values to each other.

However usually the processor, when doing arithmetic, already does certain tests anyway, and one of those tests you get "for free" is the test for zero. So in many cases (especially in the case of loops), the test for zero needs zero additional instructions; it's part of the loop arithmetic anyway.

Like

[minstrelmike]

I LIKE that Mark. If I were on the fBook, I would click a button 4u.

When running laps

[nayrbn]

We often say that immediately after starting to job on the track we are on first lap. Then we reach our second, then our third, and so on, updated each time we cross the starting point. But I hate this and would much rather start with zero. Does anyone else feel the same way? I liked to say to myself, "I've completed no laps," then "I've completed one lap," and so on, instead of "I'm on my first lap," and "I'm on my second lap." Better to count what one has already done instead of what one plans to do.

Re:Why do programmers start counting at zero?

[sgbett]

Sure its a computer thing - computers just count 2 states, zero and one ;)

Re:Why do programmers start counting at zero?

[pr0fessor]

the basic arrays, generic list, etc... are all 0 I can't think of anything in the .Net framework itself that indexes at 1 but I've seen 3rd party classes with indexes that start at 1 and it is annoying.

Re:Why do programmers start counting at zero?

[ColdWetDog]

C is merely a wrapper for assembly that's suffering from various wardrobe malfunctions.

Ooo. I like that.

It's actually only 9,999,999 kids....

[tekrat]

Because you have to start counting kids from ZERO.
Don't you guys read your own articles?

Down the waterfall

[SuperKendall]

That's no big deal, since CSEdWeek has pushed back the delivery date for final Hour of Code tutorials from its prior little-time-for-testing due date to Dec. 9th

Software industry, is there nothing you cannot deliver late, not even a simple description of a loop?

There are 10 types of people in the world

[safetyinnumbers]

Those who count from 0 and the other 10 types.

Re:They don't. - They really don't.

[Obfuscant]

I start counting at zero. "I have zero bottles of Mt. Dew, it is time to go to the store."

Kids naturally start counting at zero. "I have zero breakfast from my parents today, I'll be fed for zero dollars at school." "I'll learn zero about ... today...".

If the lowest counting number you know is one, then you have a real problem. "I don't know how to count how little Mt. Dew I have, I don't know what I'll dew ..."

One Question

[Anonymous Coward]

If 0 is now then new 1, what represents nothing?

Re:One Question

[g0bshiTe]

NULL or 4chan.

Your choice.

What if...

[srvineet]

...only 9999999 kids get the invitation email?

It's not a public performance

[Chemisor]

When you make a video, that is not a public performance. It is a cover recording. Now, if he had released it as audio only, he would only have to purchase a mechanical license for something like $0.07 per copy. Granting mechanical licenses is mandatory for the copyright holder and the price is set by the government. Unfortunately, mandatory licensing does not apply to audio-video sync licenses, which is what you need if you make a video. AV sync licenses must be purchased directly from the copyright holder and he is free to refuse your request or charge any price he wants for it.

In practice, this means that little people like you and me can not get one. It also means that for us there is no legal way to post covers on YouTube. Now, YouTube has agreements with some copyright holders (we don't know which ones), who decided to not prosecute us for doing so in exchange for putting ads next to our videos. This means that you usually get away with it, but occasionally might roll some bad luck, get sued for millions, go bankrupt and starve to death. Kind of a russian roulette.

Mark Zuckerberg is big enough to negotiate a license, but he might do us all a service if he spent that money on lobbying congress to update copyright laws for the digital era. Like, for example, by extending mandatory licensing to all contexts and work types, not just audio covers.

Re:Why do programmers start counting at zero?

[BitZtream]

Thinking its not a programmer thing shows ignorance.

Just because not all programmers use languages that start indexing at zero doesn't make it any less of a programming thing. And for reference, you can start your indexes at 1 in C too if you want, just adjust your base offset properly.

I'd say if anything, you're the one showing narrow experience, but I know nothing about you ;)

I believe you mean 0 AM

[sladman.returns]

0 AM, otherwise notated as 00:00:00 on a 24-hour clock. So, the first hour is labelled zero, the first minute is labelled zero, and the first second is labelled zero. (Ask me about milliseconds...! ;-)

Re:I believe you mean 0 AM

[TangoMargarine]

He said 0 PM. Which would apparently be 1200?

Polytheists, Monotheists, and Athiests

[sladman.returns]

We starting counting at infinitely many gods. Then we moved on to just many. The Abrahamic religions have moved on to just one. ... and they've almost converged on the correct answer. :-)

Re:They don't. - They really don't.

[fatphil]

> I start counting at zero. "I have zero bottles of Mt. Dew, it is time to go to the store."

In that instance, you're counting down the number of bottles left. And zero is the value at which you *stop* counting.

Not only that, but he misses the point entirely

[sladman.returns]

The author of exple.tive thinks that it's all about execution, efficiency, which his sources clearly indicate it's not -- but he's so hung up on execution efficiency being the most important thing in his mind that he doesn't even realize what his sources are saying. It's actually all about ease of programming. The logic of offsets is easier to follow when indexing from zero. Full stop. (That said, as others have mentioned, people still count from one.)

In related news ...

[PPH]

... Zuckerberg To Chop One Finger Off 10 Million Kids.

Just to enforce counting from 0..9.

Simple

[Murdoch5]

0 is the first number, so everything should start at 0. When you're born you aren't 1 you're 0, 0 is the logical first place to start for counting.

Re:Alls not well.

[skywire]

>0 is the first index of a typical storage location, it isn't because it is useful for counting, it is because it is base10.

This is to bring your typo about base10 to your attention so you can correct it before you get flamed.

Sports Figure Really?

[g0bshiTe]

I think when you throw in a sports star your credibility gets divided by zero.

No apostrophe? Damn English!

[raymorris]

AC's comment.
Slashdot's we site.
It's thing? No, its thing.

Damn it, I've been doing it wrong all this time. Damn English. Maybe "Ive" been doing it wrong; I don't know any more! Maybe I dont know. Crap.

Re:Why do programmers start counting at zero?

[TangoMargarine]

Exactly the reason why I'm confused when the people where I work refer to C++, C#, and .NET separately on occasion.

judging world's smallest self-replicating program

[raymorris]

There was a contest for the smallest program that produces as output its own source code. Count the characters in the winning entry, which follows:

Never that simple

[slew]

0 is the first number, so everything should start at 0. When you're born you aren't 1 you're 0, 0 is the logical first place to start for counting.

0 may be the first non-negative number, but the first counting number (aka positive number) is 1.
Also, if you happen to be chinese, you are 1 when you are born (which depending on your politics is a reasonable rounding given the fact that 9>12/2 ).

Re:Never that simple

[Murdoch5]

Good point, but I still think it makes more sense to count the first index as 0 vs 1, 0 means you can access index -1, or 1 as the next hop which to me makes more logical sense when I think of arrays.

How Many Friends

[TechNeilogy]

I'm confused. Does this mean we all have one less friend than we thought, or one more?

Counting from music and time context

[Twinbee]

Both types of counting are useful in various circumstances. As a piano teacher, it always bugs me how counting time starts at one (1,2,3,4, 1,2,3,4 etc.). No matter what your opinion for starting with zero or one in a programming context, it is insane to start from one when counting time, but tradition has the final word unfortunately.

Placing down apples on a table, or referring to an element in an array is more arguable, but perhaps the most 'accurate' (though not the most practical) method is to count in pairs: 0..1, 1..2, 2..3 etc. This way you're referring to an apple which isn't a single point in mathematical space, but rather a RANGE of points from 0 to 1. This way half an apple makes sense too.

Re:They don't. - They really don't.

[luis_a_espinal]

> I start counting at zero. "I have zero bottles of Mt. Dew, it is time to go to the store." In that instance, you're counting down the number of bottles left. And zero is the value at which you *stop* counting.

Or you are counting from a point where you can only count up (.ie. I inherited a back-log of bugs of which zero have been fixed). Zero is the value at which you *start* counting and you stop when the number of fixed bugs equals the total # of bugs in your back-log.

We can dice it anyway we want, counting is counting, independent of reference, or direction.

Re:They don't. - They really don't.

[Obfuscant]

In that instance, you're counting down the number of bottles left.

I open the fridge door. I start counting UP from zero. If there are no bottles, then I stop at zero.

I am not counting DOWN because there wasn't ONE bottle to have counted down from. I would be counting down if I said "I've just taken one bottle out and now there are zero", but that's still counting, and that's not the situation I spoke of to start with.

Now just teach the little bastards

[kilodelta]

How to count in Binary, Octal and Hexadecimal.

Zero index never bothered me.

[nedwidek]

I never really questioned it. Mainly because I started with Basic, but quickly moved into 6502 assembler on the C64. Really stupid example that creates a 30 element array on the zero page with the set [1, 4, 7, 10, .....]

        Array = $00

        LDX #$01
        LDY #$00
loop:
        STX Array,Y
        INX
        INX
        INX
        INY
        CPY #$1E
        BNE loop

If I started my index in the Y register with 1 my first element would have been placed in memory location $01 and the array would have been 29 elements long. Instead I start it with 0 and my array goes in $00 through $1D and consists of 30 elements. It had always been my assumption that 0 indexed arrays were a carry over from this.

There's no reason that a high level language can't use indexes that start with 1. It just feels really strange to me using a language that does.

Zuckerberg to confuse 9,999,000 kids

[Culture20]

Zuckerberg to confuse 9,999,000 kids to get 1000 kids who can correctly count starting with 0.

Re:They don't. - They really don't.

[segin]

Kids naturally start counting at zero. "I have zero breakfast from my parents today, I'll be fed for zero dollars at school." "I'll learn zero about ... today..."

Why does it feel like there's some kind of comment being made here about the National School Lunch Program?

Re:HUMANS count from zero!

[ccanucs]

No I think he nailed it right there :-)

Re:Up Next...

[ccanucs]

This is quite easy to do with Perl. A box with nothing in it has an undefined value. A box with something in it - even it's 0 or empty string has a defined value.

Re:Nonsense!

[ccanucs]

No sane programmers use the G word :-)

Re:Simple

[ccanucs]

When you're born you're 9 months old. Maybe we should start with fractional years :-)

Re:Kudos for starting with zero!

[ccanucs]

I liked the idea of teaching "number lines" by height above the ground. Dig a hole it's negative. Stack blocks above it's positive. The ground is 0.

Re:Simple

[Murdoch5]

I guess technically you are lol, but in either case you're still not 1.

Because C is wrong, unlike Pascal or Algol

[DutchUncle]

... in which you can specify whatever you want for your lower and upper indices and the compiler just figures it out for you. C requires the programmer to confuse "counting" and "indexing" and wind up doing them wrong. Zero, rather than meaning "nothing" like it does in the rest of all meaning, means "the first" - which is not counting one. I never expected that after all these years I'd still be programming so close to assembler.

Re:Simple

[ccanucs]

But, since you're "1" 3 months after birth though, that's why we need fractional years ;-)

Re:Simple

[Murdoch5]

LOL! Well we could make a language that uses fractions. So if your array had 10 index's the first would be Array[1/10]

Re:Simple

[ccanucs]

Or, we could use, say, Perl and do it in an associative array like so

@years_so_far{map{'0.'.$_;}(0..8)} = ('womb') x 9;
$years_so_far{'0.a'} = 'milk';
$years_so_far{'0.f'} = 'beginning solids';

  and so on ;-) and teach fractional hex while we're at it.