Again on 0-based vs. 1-based indexing

One thing I would hope there is consensus on is that 1-based indexing is easier to <i>learn</i>. My son is doing Python at school, and the &quot;first-element-is-actually-element-zero&quot; is something that has to be dinned into them, a sure sign that it is non-intuitive. In similar vein, as adult programmers we know that the half-open range is the most useful mechanism for expressing a sequence, but again we have to explain to kids that if they want the numbers 1 to 12 (eg to do a times table program) they must type range(1,13), which at that stage of their learning just seems bizarre. Actually I could go on at length about why Python is a terrible teaching language, but I&#x27;ll stop there !

0-based indexing with closed intervals is better for slicing. This shouldn&#x27;t be controversial. It&#x27;s because you can represent a zero interval cleanly: [3,3) is an empty interval after slot 2, representing a single cell is [3,4).<p>This has two nice properties. One is that two slices are adjacent if the beginning and ends match, and the other, far more important, is that the length of the slice is <i>end - start</i>.<p>That&#x27;s the one that really gets us something. It means you can do relatively complex offset math, without having to think about when you need to add or subtract an additional 1 to get your result.<p>I use Lua every day, and work with abstract syntax trees. I mess this up all. the. time.<p>Of course you can use closed intervals and stick with 1-based indexing. But for why you shouldn&#x27;t, I&#x27;m going to Appeal To Authority: read Djikstra, and follow up with these.<p><a href="https:&#x2F;&#x2F;wiki.c2.com&#x2F;?WhyNumberingShouldStartAtZero" rel="nofollow">https:&#x2F;&#x2F;wiki.c2.com&#x2F;?WhyNumberingShouldStartAtZero</a> <a href="https:&#x2F;&#x2F;wiki.c2.com&#x2F;?WhyNumberingShouldStartAtOne" rel="nofollow">https:&#x2F;&#x2F;wiki.c2.com&#x2F;?WhyNumberingShouldStartAtOne</a> <a href="https:&#x2F;&#x2F;wiki.c2.com&#x2F;?ZeroAndOneBasedIndexes" rel="nofollow">https:&#x2F;&#x2F;wiki.c2.com&#x2F;?ZeroAndOneBasedIndexes</a>

In mathematics, both are common. For example, when working with polynomials or polynomial-like things, it is common to label coefficients starting with 0. E.g., a0 + a1 x + a2 x^2 + ...<p>The subscript on the coefficient then matches the power of x, letting you write the general term as ai x^i, which works out great when using capital sigma notation.<p>One the other hand, matrix rows and columns usually start from 1, so the elements on the top row are usually a11, a12, a13, ..., and the next row is a21, a22, a23, ..., and so on.<p>In an attempt to bring some unity to the two sides on this issue in programming, let me offer something that I&#x27;m sure <i>everybody</i> will be able to agree on.<p>Once upon a time I was implementing some mathematical code in C++. It was a mix of things from places where mathematicians would number from 0 and where they would number from 1.<p>I decided that the code would be clearer if the code looked like the formulas in the math papers they came from, which meant I wanted to use 0-based arrays in some places and 1-based in others.<p>Solution: I overloaded the () operator so that array(i) was a reference to array[i-1]. Then I could use 0-based or 1-based, depending on whether I was using a formula that came from a 0-based or 1-based area of mathematics.<p>Everybody agree that this was not a good idea?

TBH indexing became much less important with every language adopting some sort of &quot;for all&quot; and map&#x2F;filter&#x2F;reduce constructs. If you don&#x27;t care about indexes you don&#x27;t need to think about them (finally!).<p>The remaining cases are by definition edge cases and warrant enough attention that bugs caused by 1- vs 0-based indexing doesn&#x27;t seem to be a big problem in practice.<p>It&#x27;s like with goto and structured programming - people stopped using goto for loops and ifs, so the remaining cases where goto is used as last resort aren&#x27;t much of a problem. People think hard before doing this.

I was hoping for an interesting analysis of 0 vs 1 based indexing, but instead got a 3 page rant of HN-this and appeal-to-authority-that which adds absolutely nothing of value to the discussion. It feels more like a bottom-of-the-page angry comment to an article than an actual article.

Here&#x27;s two arguments arguments in favor of 0-based &#x27;indexing&#x27; (or offsets), that aren&#x27;t just &quot;because that&#x27;s how it&#x27;s done&quot;:<p>1. It is faster. Due to how memory works, 1-based languages need to subtract 1 internally every time you access an array[1].<p>2. It works mathematically better with some of the most common operations on array offsets, like modulo and division into round&#x2F;ceil&#x2F;floor. You&#x27;ll be peppering your code with +1 or -1 around those a lot if you use 1-based indexing.<p>[1]: This is lua, for instance: <a href="https:&#x2F;&#x2F;github.com&#x2F;lua&#x2F;lua&#x2F;blob&#x2F;master&#x2F;ltable.c#L702" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;lua&#x2F;lua&#x2F;blob&#x2F;master&#x2F;ltable.c#L702</a>

&gt; It really shows how conditioned an entire community can be when they find the statement “given a list x, the first item in x is x[1], the second item in x is x[2]” to be unnatural.<p>It really shows how conditioned the mankind is that they call the &quot;0th&quot; ordinal number by the name &quot;first&quot;. We have never moved past the phase where the concept of &quot;zero&quot; was heretic.<p>Here + offset makes SO much sense. I think we should move to use it in other contexts too. &quot;0 steps from the start of an ordered list&quot; &quot;1 step from the start of an ordered list&quot; etc.<p>At the moment we are using two different &quot;scales&quot; for measuring things and labeling orders. We could as well use the letters &quot;A&quot;, &quot;B&quot;, &quot;C&quot; for the latter, and it wouldn&#x27;t change a thing. Hindsight is 20&#x2F;20, but it&#x27;s just a confusing mishap that we are using &quot;numbers&quot; and &quot;numbers + 1&quot; for the two purposes, where the second one could be expressed just as another &quot;measurement&quot;, and we could get rid of the confusing &quot;numbers + 1&quot; scale.

Disclaimer: I don&#x27;t care about this argument one way or another. However I found the author missed the point (as perhaps many commenters did?)<p>&quot;...nowadays, all arguments that say that indexes should be 0-based are actually arguments that offsets are 0-based, indexes are offsets, therefore indexes should be 0-based. That’s a circular argument...&quot;<p>Yes, that is a circular argument. It&#x27;s not the one I would use. C made the decision that indexes and pointers are the same thing. It&#x27;s a logical argument and one that&#x27;s not circular. If they&#x27;re separate things, then yes, you end up in a circle.<p>For languages that are not C-like, you could argue &quot;pick an idiom and stick with it across multiple languages&quot; or &quot;make programming languages easier for humans to understand&quot; Both of those arguments are preferential arguments. Perhaps there could be a study comparing the merits of each, but I haven&#x27;t seen one yet.<p>I like chocolate ice cream. I like making pointers and arrays as similar as possible. I like being able to collapse pointer arithmetic down. I like doing huge mallocs and then playing around with large, empty hunks of memory. Some folks don&#x27;t. I get it. Code should look like the way we think about the problem. That&#x27;s an ideal state we&#x27;ll never reach, but it&#x27;s worthy of continued discussion.

Do not add any more fuel to the flame and instead use 2-based indexing: <a href="https:&#x2F;&#x2F;github.com&#x2F;simonster&#x2F;TwoBasedIndexing.jl" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;simonster&#x2F;TwoBasedIndexing.jl</a><p>Seriously, the exact value of the lower bound for indexing doesn&#x27;t matter here (some algorithms are best described with the lower bound other than 0 or 1, for example). The fixed or preferred lower bound is the real problem. Any argument for&#x2F;against 0-based and 1-based indexing tends to gloss over the real problem because those arguments only exist to make some languages look better than other languages. As we move away from forced explicit indexing (e.g. arr.first() or foreach instead of arr[$LBOUND] or `for (i=$LBOUND; ...)`), it becomes clear that there is no such thing like the preferred lower bound for sequences at all.

Just like big- vs. little endian issue, the differences matter less than everyone adopting one. When you program having two code sets with different base of indexing is several times worse than either alone.<p>0-based indexing is here. 1-based has no benefit. New languages should use 0-based indexing.

I kinda take issue with his complaining about referring to Dijkstra&#x27;s argument as being an argument from authority. Dijkstra makes a pretty solid case in his writing, it&#x27;s not just about him being Dijkstra.

While I think these debates healthy (when they&#x27;re civil and well grounded), found out that I don&#x27;t have any preferences for one over other for things like array indexing.<p>Every language has its own design decisions based on some requirement or opinion, and while I have rather strong preferences about languages, these kind of design decisions doesn&#x27;t strike any nerves.<p>As long as it&#x27;s usable, that&#x27;s fine by me.

There are many situations where 1-based indexing is more natural. There are also many situations where 0-based indexing is more natural. And also many (possibly most?) situations, where it doesn&#x27;t really matter.<p>My 2 cents: it isn&#x27;t really that important. As long as the developer is aware of whether the language they are currently using 0 or 1 based indexing.

For a general purpose programming language 1-based indexing probably causes more confusion and errors than benefits. A language trying to be a general purpose computer programming language shouldn&#x27;t abstract in a way that&#x27;s likely to lead to confusion with those that understand the fundamentals.<p>For a domain specific language focused around simulating physical things, or a specific application, 1-based indexing may be the more appropriate option. In this case, abstracting the problem domain is likely more important than adhering to the limitations of hardware.

Linking to Dijkstra does not have to be an appeal to authority. I happen to find his position to be persuasive on its own merits.

I don’t have any experience working with 1-based indexing, but it seems reasonable. I certainly remember how confusing 0-based indexing felt for a long time when I first learned to program.<p>On the other hand, I’ve made an observation about timelines in music production software, where bars are counted starting from 1. As you zoom out, only every 4th bar tends to be labeled, which creates this strange sequence: 1, 5, 9, 13, 17… I always found that incredibly hard to reason about, and perhaps it would have been a better idea to label the first bar as 0.

0-based indexing is preferable because the mathematics of half-open intervals make composing ranges far simpler. It becomes a bit more obvious as soon as you do any kind of non-integer ranges, because you find that only integers have a reliable &quot;subtract one&quot; operation.<p>For instance, suppose you&#x27;re doing a lot of date arithmetic, and you <i>might</i> include times. If I have a range:<p><pre><code> [2005-05-05, 2007-07-07) </code></pre> This unambiguously includes all times. If I compose it:<p><pre><code> [2005-05-05, 2007-07-07) [2007-07-07, 2008-08-08) </code></pre> If I shift all of them forward 10 days:<p><pre><code> [2005-05-15, 2007-07-17) [2007-07-17, 2008-08-18) </code></pre> Every possible time within the new range is accounted for. Transformations on the ranges are obviously correct. If we can&#x27;t agree on whether time resolves to seconds, milliseconds or nanoseconds, it doesn&#x27;t matter.<p>That&#x27;s because you can find the beginning and end of a range without knowing how to subtract by one. If you later decide to add times, it will just work because, conceptually, you already handle every possible value in the range.<p>If you want to construct a series of ranges of floats, it&#x27;s a bad idea to do [3.457, 6.799999], [6.8, 12.47699999]. If you use half-open intervals, it just works, without mucking with the end of the range.<p>This is the reason that &quot;indices are offsets&quot; is powerful: it&#x27;s not circular reasoning, but a simplification because we&#x27;re removing an unnecessary primitive (subtracct 1) that only reliably works with integers.<p>And to bring this back to integer offsets, even when you&#x27;re working strictly with integers, you may want to conceptually work with rational numbers.<p>When you&#x27;re working out your math for buffered IO, you need to map byte indices to chunk indices. You need to assign every byte written to a chunk.<p>In a 0-based world, your chunk offset is simply your byte offset &#x2F; chunk length. Because there is no distinction between indices and offsets, it&#x27;s a clean mapping between one offset scheme and the other.<p>It means you can work out on paper when a new chunk should be started, and then translate that into integer arithmetic. And your code directly reflects the math, rather than having to stick &quot;- 1&quot; and &quot;+ 1&quot; in here and there.

&gt; It really shows how conditioned an entire community can be when they find the statement “given a list x, the first item in x is x[1], the second item in x is x[2]” to be unnatural.<p>It&#x27;s not unnatural, but it&#x27;s not natural either. It&#x27;s just that 1-based indexing aligns with natural language conventions better. It also matches with some math conventions for matrices and vectors, but those don&#x27;t have to use 1-based indexing either to work. I learned linear algebra with abstract &quot;index sets&quot; (I), where <i>I</i> can be {1, 2, 3, .., n}, {x,y,z}, {0,1,2}, whatever.<p>Programming in 0-based indexing means way less +-1 adjustments on boundaries. Division&#x2F;modulus also works way better with 0-based indexing, so flattening multi-dimensional arrays is more easily expressed too.<p>In the end it&#x27;s just a convention, it shouldn&#x27;t matter too much. My money is still on 0-based indexing, as it lends itself to less errors and cognitive load when you get used to it. I used both extensively.<p>Tangential: conventions that are more &quot;natural&quot; are usually not actually natural, but just align themselves to other conventions better. Of course it&#x27;s always good if conventions align, but sometimes it&#x27;s inconsequential. Also there are situations where we can&#x27;t make all conventions align.<p>An other little pet-peeve of mine is people calling big-endian more natural than little-endian, where there are actually different competing conventions:<p>1. Usual way of printing memory content from lower address to higher address from left to right (think hexdump).<p>2. Usual way of writing down numbers from left to right from most significant digit to least significant digit.<p>3. Expressing the value of the number from the byte array elements (\sum_0^(width-1) byte[n] 256^n for little-endian, \sum_0^(width-1) byte[n] 256^(width-n-1) for big-endian)<p>Big-endian aligns better with the combination of 1 and 2. Little-endian aligns better with 3.

One issue I see with 1-based indexing is that it makes x[0] undefined, so even if you pass an unsigned integer index to a function you need to verify that it&#x27;s != 0 before you use it. So in a way it&#x27;d be the whole null pointer thing for array indices all over again.<p>Another minor issue is that you can access one less element with a fixed size integer than when you do 0-based indexing. So for u8 you can only access 255 elements instead of 256 for instance.

It&#x27;s range that gets me all the time, some make the end inclusive, some exclusive.<p><pre><code> Clojure (range 1 10) ;=&gt; (1 2 3 4 5 6 7 8 9) C# Enumerable.Range(1, 10).PrintAll(); 1 2 3 4 5 6 7 8 9 10 Ruby (1..10).each { |n| puts n } #=&gt; 1 2 3 4 5 6 7 8 9 10 Python for i in range(1, 10): print(i, end=&#x27;, &#x27;) =&gt; 1 2 3 4 5 6 7 8 9</code></pre>

This is obviously spaces vs tabs third rail in PL design, but riffing off of the language in the article, probably we should all agree on two opinions:<p>0-based indexing is inherently better for machines.<p>1-based indexing is inherently more natural for humans.<p>**<p>For a short stint I was running a (small) datacenter, and despite being an apologist for 1-indexed programming languages, I zero indexed EVERYTHING in the datacenter.<p>Let me just say, that was a huge mistake. Physical items are not offsets. Even though I was then working in a 0-indexed PL, The amount of contortion I had to do to remember zero indexing made the likelihood of errors higher (I did not make any that weren&#x27;t quickly recoverable, but still).

With 1-based indexing, you can&#x27;t index the last element of an array that occupies the entire domain of the index type.

I know Visual Basic gets a bad rap, but as a learning language it had an interesting feature, `Option Base`. By putting `Option Base` in a module, it changed how the indexing of arrays worked. It defaulted to 0, but for some applications (and also, when you&#x27;re first learning), 1 can be convenient.<p>Of course, there are problems with this in a professional setting, such as how do you enforce uniformity across modules, and what happens if you copy code from one module that&#x27;s Base 0 to one that&#x27;s Base 1 and vice versa. But when I was first learning how to program, it was helpful to me to have a language that allowed for some choice.<p>In the meantime, 23 years of programming have led me to believe that index base 0 makes sense. For many applications it&#x27;s moot, because we should be using higher level functions (like map and reduce) for processing lists. In every other application (such as working with data on a grid), dealing with offsets does make things easier.<p>Perhaps the convention is arbitrary. But, lots of industries have arbitrary conventions that we all agree on just to aid communication, and I disagree with the original author that the term &quot;groupthink&quot; applies in this situation.

While 1-based index is probably easier to learn and understand for a beginner, even as a beginner there is quickly an overhead where you have to adjust indices by 1 all the time as soon as you do any math on indices. Going from Basic to C was hard for me for many reasons, but a lot of complexity in my code that I took for granted just vanished. This truly showed me the power in getting such fundamental choices right.

Why is this a thing?? Seriously, every language has its rules...just follow the rules and build something useful

What convinced me is graphs&#x27; zero origin<p>When counting apples (i.e. only +) then 1 based. but when (* % ^ √ ÷) then 0 based

Rebutting the dismissal of offsets as an artefact of an old language:<p>- pointer offsets - the article seems to dismiss these, but they&#x27;re used loads in systems&#x2F;network&#x2F;driver programming, which is a reasonable chunk of the most important programming<p>- conceptual offsets - e.g. time of day starts at zero, not one. We think in this way a lot, and it&#x27;s useful.

For things that wrap, such as ring buffer indices or packet sequence numbers in a fixed-size field or clocks (hour of the day, minutes in an hour), zero-based indexing is simple modular arithmetic. Wrapping of one-based indices can of course be done, but it&#x27;s more complicated than necessary.

Even worse is sometimes this 0-based numbering is carried over to a world of enumerable things, cargo cult like. In my project we have multiple physical entities which have numbers, e.g. blades, ports, channels on so on, all of them are counted from 0 because some genius decided to write that into standard. And now there are multiple points in the code where 1-based numbers are converted into 0-based and back, and incredibly - there are bugs there :) . Talking to humans gets equally weird and confusing when you are talking about second port numbered 1, it&#x27;s just never gets natural, even after years working on these devices.

Here’s some fuel to the flames: &lt; is less chars than &lt;= , it also is more logical. 0-based indexes have the advantage of <i>if</i> in comparison and range. Mathematics treats 0 as special and can have all sorts of side effects if dropped into a formula, code doesn’t have this side effect (unless running formula as an algorithm, which is math).<p>To save yourself from headaches, I believe 0-based indexes are preferred in almost every modern language for the simple reason of optimization. I have no evidence to back this. NULL=Nothing=0 is a thing though.

Honestly 0-based indexing is one of the most annoying things to teach. In sciences, people really don&#x27;t care about programming arcana: I have never found anyone who found 0-based indexing natural or intuitive.<p>In fact, much of the vehemence in favor of it seem to be more about programmer shibboleths, to make some people feel they are in a special &#x27;in-the-know&#x27; club (certainly if the r&#x2F;programmerhumour reddit is anything to go by).<p>All I can do for scientists is tell them the advantage of learning a programming language outweighs the weirdness.

Well... I wrote a snake game in python and lua.<p>0 based array (python) : screen_pos = x + y * width<p>1 based (lua) : screen_pos = 1 + x + y * width<p><i>shrug</i><p>So 0 based seems to work a little better for arithmetic based array references. But really you&#x27;ll never resolve this to perfection. Assembly language programmers are very unlikely appreciative of 1-based.<p>Its all about what you&#x27;re comfortable with.<p>Those wanting pointers can imagine a base address added to each calculation. 1-based then needs a -1... which is then a strange thing to advocate for.

&gt; Again on 0-based vs. 1-based indexing<p>The problem is within the phrasing and its premise: Are you using an index or an offset? 99% of the time I think of an offset, so &quot;first&quot; makes sense as &quot;0&quot;. If you go by indexing &quot;1&quot; suddenly makes sense as an index. When people say index in the context of arrays or data structures usually they mean an offset. To me it&#x27;s simply wrong phrasing.

&gt; You see, Lua uses 1-based indexing, and lots of programmers claimed this is unnatural because “every other language out there” uses 0-based indexing.<p>&gt; I’ll brush aside quickly the fact that this is not true — 1-based indexing has a long history, all the way from Fortran, COBOL, Pascal, Ada, Smalltalk, etc. — and I’ll grant that the vast majority of popular languages in the industry nowadays are 0-based. So, let’s avoid the popularity contest and address the claim that 0-based indexing is “inherently better”, or worse, “more natural”.<p>Maybe I missed the comments about 1-indexing being &quot;unnatural&quot; but if the author is referring to the discussion I took part in, then this is a strawman. It wasn&#x27;t about what was &quot;natural&quot; or &quot;unnatural&quot; but about people switching from their primary language to secondary languages and gotchas like 1-indexing being error prone.<p>We had a platform team at my last company looking to adopt Lua for client customization. The primary authors became familiar with Lua in writing the code logic but everyone else would be touching their part, or contributing back to the core, not as people familiar with Lua but as C++ developers who would be blindly making changes in another language. It felt similar to maintenance of our Perl scripts. You don&#x27;t brush up and become an expert on a language you interact with on a yearly cadence. It is important in these cases to have few gotchas to make casual contributions easier and safer.<p>This says nothing about using 1-indexing when your target audience isn&#x27;t 0-indexed programmers (speaking of those who choose to use Lua and not to Lua&#x27;s creators).<p>Unfortunately, for me, even with my complaints (this and language compatibility), I&#x27;ll probably still use Lua for some projects of mine. I&#x27;ve looked at others and I&#x27;m mainly concerned about the community size.

Honestly, I feel like `some_list.first` is the most ergonomic.<p>And if the API provides `second`, `third`, `antepenultimate`, `penultimate`, and `last` methods it covers a large part of what one most often use.<p>Past third rank, then I will feel better served with a `slice` method, whose documentation provides explicitly it’s index convention, whether it makes a modulo on out of bounds, etc.

Has this argument been rehashed much:<p>If you use 1-based indexing, you can&#x27;t iterate over a list of maximum length with a simple loop. The normal loop condition is `while i &lt; len` (0 based) or `while i &lt;= len` (1 based). If len is maximal, the second one probably has an overflow bug in the loop body that turns it into an infinite loop or a crash.

In the same way that I don’t think learning sklearn is the hard part of knowing ML, I don’t think 0 or 1 -based arrays is the hard part of any particular language. There are situations where both are appropriate. The choice of either as the deal breaker for a language is extremely superficial.

I had a ROFL moment when he discredited appeals to authority, and then progressed to note that it&#x27;s conventional math notation - which is pretty much the same kind of logic.<p>Furthermore, mathematical notation is almost universally <i>terrible</i>. It&#x27;s inconsistent, ambiguous, and has many undeclared dialects. Oh, and many people use 0-based index to boot, because, you know, whether that&#x27;s conventional or convenient (largely orthogonal qualities alas in math) depends on the context.<p>I mean, I can sort of buy his argument that it&#x27;s arbitrary, but then he also points out that there&#x27;s at least one advantage to 0-based indexing, namely that works well in offset based scenarios (not just for pointers). So in which case is 1-based indexing convenient? Based on this blog post, never.

The harder it is to learn, the more it takes you to change your mind. It&#x27;s hard to see things without bringing baggage<p>Also, the irony of complaining about HN holy wars becoming just another trigger to continue! I&#x27;ll do my part - whichever side you are on - you are wrong.

An interesting perspective is what this does to pointers in terms of unsigned representation, effectively making 0 a special case which could be used for null. But in practical terms it would just limit 32 bit systems to 31 bits of adressable memory, or make pointer arithmetics wierd. The latter isnt that much of a problem, as its only when pointers are basic types it matters, and free pointer arithmetics is a mistake whose only advantage is compiler speed, not even application speed.<p>For instance, even in slicing, [start:end) eliminates this issue. Though there is something to be said for verbosity.<p>I think this becomes an argument for 0 based indexing, but a case could be made to the opposite.<p>That said, consistency is what is valuable, so the only truly wrong answer would be the one we use in real life.

I don&#x27;t understand why the author treats referring to Dijkstra&#x27;s paper as &quot;appealing to authority&quot;. To me it is natural to defer to a well-written paper instead of repeating the same arguments in your own words, regardless on who wrote it.

We can&#x27;t even agree on this for floors of buildings. Half the world starts at &#x27;G&#x27; then 1, 2, 3 etc. as you go upwards, the other half starts at 1, then 2, 3 etc.<p>And then you have Japan which sometimes starts at 2F. Hey, maybe we should use 2-based indexing.

sometimes i program in Lua (which is 1-based) but mainly i write code in 0-based languages.<p>The worst is really when you switch between the languages, but after a while you get used to it.<p>You just need to watch out like a hawk, when calculating the index of the last element ;)

I grew up on languages that were 1 indexed - BASIC, VB, VB.Net. It took me a long time to get used to 0 indexed, primarily in college and later in working with more C inspired languages, yet I think 0 indexed is superior. Why?<p>Numbers in programming start at 0, even in the languages with 1 indexing. Period. When I initialize an integer, unless I explicitly set a value, it’s 0.<p>From a purely pragmatic standpoint, making the first number an invalid location in a list just adds unnecessary complexity and increases the odds of off-by-one errors. On the same token, there’s nearly no benefit to starting at one.

The biggest thing about index 0 or 1 is the inclusive and exclusive slicing. When the index is 0 and the slicing is [inclusive:exclusive], I find it a bit easier to write code with array manipulation.

This was submitted yesterday [0], w&#x2F; discussion today.<p>- [0] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=25829966" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=25829966</a>

I am pretty sure that the last, counterfactual, paragraph of this article is spot-on.<p>Personally, I am not so much interested in which way is more right, but which way is less likely to result in off-by-one and related errors, though I do not know how you could gather data on that, other for people beginning programming, and any difference might go away or even flip as programmers gain experience and move on to more difficult problems. (Of course, the most effective solution is to not use indexing at all, except where absolutely necessary.)

Citrine is also 1-indexed (<a href="https:&#x2F;&#x2F;citrine-lang.org&#x2F;#lists" rel="nofollow">https:&#x2F;&#x2F;citrine-lang.org&#x2F;#lists</a>), I think this would help people who are not developers to read and possibly verify code a bit easier. Of course it is just a small step, but I feel code in general is drifting away from the normal users, who seems to be confine to graphical interfaces. Wasn&#x27;t it an objective once in the software development community to try and make code as accessible as possible?

&quot;... of course, nowadays the number one reason is tradition and familiarity given other popular languages, and I think even proponents of 0-based indexing would agree, in spite of the fact that most of them wouldn’t even notice that they don’t call it a number zero reason.&quot;<p>That&#x27;s it, I&#x27;m switching to saying number 0 reason from now on. If you are talking about your number 1 reason, I will forever be wondering what your number 0 reason would be. I&#x27;ll tell my wife tonight she is my number 0!

Pascal, contrary to what the article states, allows any subrange of integer as an array index. For example,<p><pre><code> kernel: array[-3..3,-3..3] of real; </code></pre> is a 7x7 array. It has negative indices, e.g.<p><pre><code> x := kernel[-3,-3]; </code></pre> See <a href="https:&#x2F;&#x2F;www.tutorialspoint.com&#x2F;pascal&#x2F;pascal_arrays.htm" rel="nofollow">https:&#x2F;&#x2F;www.tutorialspoint.com&#x2F;pascal&#x2F;pascal_arrays.htm</a><p>Sometimes you want negative indices, e.g. when performing a convolution on an image with a kernel.

Maybe the confusion comes from the fact that programming languages don&#x27;t make a distinction between cardinal and ordinal numbers.<p>In English we do. For example, if you are nine years old, you are in your tenth year. If an array has ten elements, the last element is the tenth element, it is nine elements away from the beginning. We could do &quot;int array[10]; array[10th] = x;&quot; if we wanted to mirror that.<p>We could imagine a language that does the distinction, but I don&#x27;t know what good it would do.

Wacław Sierpiński (1882–1969), the namesake of Sierpiński&#x27;s triangle, was famously a proponent of zero-based indexing, including in everyday life. Sadly, I can only find sources in Polish that corroborate this [0].<p>[0]: <a href="https:&#x2F;&#x2F;wyborcza.pl&#x2F;AkcjeSpecjalne&#x2F;7,160474,24501452,zaczynali-od-zera-stali-sie-legenda-jak-warszawscy-matematycy.html" rel="nofollow">https:&#x2F;&#x2F;wyborcza.pl&#x2F;AkcjeSpecjalne&#x2F;7,160474,24501452,zaczyna...</a>

I settled on 0 based indexing as the right way to go when I was doing this calculation: <a href="https:&#x2F;&#x2F;madhadron.com&#x2F;posts&#x2F;2009-07-17-determining-affine-transforms-from-three-points.html" rel="nofollow">https:&#x2F;&#x2F;madhadron.com&#x2F;posts&#x2F;2009-07-17-determining-affine-tr...</a><p>When you start calculating offsets and transformations of coordinates, starting at 1 forces you to carry around extra additive constants everywhere.

As weird as I find 1 based indexing(looking at you R) I still get confused by 0 based indexing. This happens all the time when I’m working in pandas and thinking about line numbers in the file vs the data frame, and I recently had an issue with this while implementing Conway’s Game of Life in Racket, while I was traversing the array and when I was looking for neighbors.<p>It has been enough of an issue for me to seriously reconsider my stance on indexing

After some experience with Go I realized that in quite a few cases it will be nice to have 1-based indexes. If one have a variable that is an index into an array, then it is natural to initialize it to an invalid index like -1. But in Go everything is initialized by default to 0. So to get -1 one needs extra code.<p>With one-based indexes zero would be a very natural invalid value as an index similar to a null pointer.

My own opinion is that zero based indexing is generally much more useful, and makes a lot of things things simpler and&#x2F;or more sensible mathematically or otherwise. However, there are some cases where an index based on some other number (often, but not necessarily, 1) is more useful. (Some programming languages, such as BASIC, allow you to define whatever starting index that you want to do.)

It does not seem like a big deal, both conventions are easy to understand and natural to use. Except if you work with the discrete Fourier transform. Then 1-based indexing is extremely cumbersome and annoying. More generally, if your indices are to be understood &quot;modulo N&quot;, it makes sense that they are all strictly smaller than N (or even signed, and centered around 0).

Unfortunately off-by-one errors can be insidious and non-obvious to debug, having different systems only complicates this. 0-indexing makes sense for systems and computer programming while 1-indexing makes translating math more straightforward. Inter-converting between the two systems is unfortunately non-trivial, even if the cost isn&#x27;t that high.

I think it just comes down to where you want your index-out-of-range errors to occur.<p>Pretty much any language I can think of inits primitives with all bits set to 0. So either, you accidentally forget to set your index vars to 1 and out-of-range it there, or accidentally forget to take away 1 when accessing the end of the array. Pick your poison

This reminds me that because array access is just addition, in C you can also write 2[a] to access the third element of a.

The APL language has this system variable ⎕IO (called QUAD IO -- index origin), which could be set to 0 (for 0-based indexing) or 1 globally in the environment.<p>Also, ⎕IO can be set as a local variable of a function to limit the scope of the indexing origin, which made it convenient to simplify the code to implement certain algorithms.

Maybe we should be counting from zero in general?<p><a href="https:&#x2F;&#x2F;lasvegassun.com&#x2F;news&#x2F;2016&#x2F;nov&#x2F;07&#x2F;the-human-calculator-is-fixed-on-helping-young-peo&#x2F;" rel="nofollow">https:&#x2F;&#x2F;lasvegassun.com&#x2F;news&#x2F;2016&#x2F;nov&#x2F;07&#x2F;the-human-calculato...</a>

The funny thing is that even in natural language we don&#x27;t use base 1 or 0 consistently.<p>For example why is the 1st of January the first day of the month&#x2F;year, but your first birthday is when you turn one year old, i.e. when your first year of life finishes.

I&#x27;d say from a mathematical perspective, 0-based indexing makes more sense, simply because the Peano axioms start with 0 for the natural numbers. Also, thinking of overflows makes more sense this way, because it&#x27;s just modular arithmetic.

Until Perl v5.30 it was possible to set how you would index with &quot;$[&quot; variable.

The first element being at index 0 feels as natural as 0 being the first natural number.<p>Or let me rephrase that in the interest of avoiding natural language bias.<p>The starting element being at index 0 feels as natural as 0 being the starting natural number.

Discussing about 0 vs 1 indexing is like questioning the key layout of a piano. Sure, one is probably easier to learn than the other but in the end its an interface everyone is used to.

Indexes start at 1. Offsets start at 0. They are different things.

The crazy part is that Lua accepts &quot;array[0]&quot; just fine and it works <i>exactly</i> as expected. This is a non-issue in Lua but many people cite it as a problem.

Previous discussion: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=25829966" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=25829966</a>

I never thought I&#x27;d say this, but you&#x27;ve got to give props to VB where you can declare the starting (and ending) index of your array to be whatever you want!

This is something that&#x27;s extremely annoying to deal with in a genomics context. Various formats in the field uses 0-based or 1-based and inclusive or exclusive.

Mystery solved<p><pre><code> 0 1 2 3 4 5 v v v v v v |---|---|---|---|---|---... ^ ^ ^ ^ ^ ^ 1 2 3 4 5 6...</code></pre>

I don&#x27;t know if one is somehow &#x27;essentially&#x27; better, but 0 based indexing have clearly won as a convention.

This is a true hacker mindset. Love the fact that the author is questioning the groupthink here in a constructive way.

While I don&#x27;t have a strong preference in this &quot;war&quot;, I can think of an interesting argument for 1-based.<p>Our time counting is 1-based. There is no zeroth second, zeroth minute, hour, day, month, year, or century. This actually makes it slightly harder in 0-based languages to work with time and dates.<p>Also, it might be an indication that 1-based system is somewhat more intuitive to non-programmers.

A newborn is not one year old.<p>Midnight is not 01:01 AM.

This is why in languages like pascal or Ada you can make an array that runs from 7 to 35.

Are there any languages with reversed indexing, or some other more bizzare options?

Python supports -1 based indexing, so clearly that&#x27;s the superior convention.

Erlang is kinda interesting.. 1-based, but you might never need to know that.

i don&#x27;t really care if the language has me start counting indices at 0 or 1. it&#x27;s never been the part of the problem of programming that has caused me significant trouble.

Counting in binary gets pretty boring if you have to start from 1.

Well yes, Python or js don&#x27;t have pointer arithmetic but underneath that&#x27;s what happens if you&#x27;re dealing with an array<p>Zero indexing might look weird at first but I think it helps in most cases.

I find zero-based indexing more natural. Consider the case of dates. Dates are naturally one-indexed. There is no year zero.<p>This means that the 21st century started in the year 2001. Likewise, the current decade started under a month ago, not over a year ago. If you think the 21st century started in the year 2000, as do most people, then that implies that the first century either started in the year 1 B.C. (ugly) or was only 99 years long (not a century). People naturally (and incorrectly) default to zero-based indexing in this case!<p>I would go farther and make centuries zero-indexed too. It&#x27;s far more natural to say that the Nth century is everything in the form Nxx than to say it&#x27;s (N-1)xx. Every time I run across a numbered century I have to stop and think for a split second to calculate what years it covers. I got this wrong on several occasions in grade school and was marked down for it.<p>Zero-based indexing works naturally for grouping things. One-based indexing does not.<p>This, of course, doesn&#x27;t matter much.