It's the difference between numbering the contents of the list (1 indexing), and measuring the distance from the beginning of the list to the start of the item (0 indexing).

Personally I'm happy to switch between both, and they both have positives and negatives when I actually write code.

0 indexing is not incorrect, or incompatible with maths, it is just a different way of conceiving of lists/arrays by considering the index to more like the distance from the beginning. The first item begins 0 spaces from the start position.

That is why in that context array length is usually the highest index + 1, because length is the distance from the start position to the end of the list, whereas the index is the start position of the item in the list.

I will concede that 0 indexing is a little too close to the storage paradigm for arrays (i.e. a sequential list of items of n bytes) and that when so often these arrays point to more complex data-structures / objects, the distance doesn't make as much sense as the item number... but meh - I'd take Python generators / iterators at the expense of 0 indexing any day.

>It's the difference between numbering the contents of the list (1 indexing), and measuring the distance from the beginning of the list to the start of the item (0 indexing).

The problem is that one is indeed an indexing (numbering the contents 1...X...N and asking for item X, customers[X]), whereas the other is not, but is used as an indexing (e.g. customers[5] is not getting the 5th item but the sixth).

Where does your definition of "an indexing" originate? The word "index" literally means "to point at" (hence, index/pointer finger), and in this sense, every element may indeed be indexed -- in this case, by means of a unique integer.

If I had to give a name to the concept you're talking about, it would be an "ordinal index".

Index finger, or first finger, right next to the zeroeth finger, the thumb... ;)

>If I had to give a name to the concept you're talking about, it would be an "ordinal index".

Which is both the naive understanding of a numeric index in everyday life in general, and the most common case in mathematics (and most math/scientific software).

In 1-based arrays the number is an index, but in 0-based arrays it is an offset. Languages like C or Rust make this behavior very explicit.

You have forgotten Algol, PL/I, Pascal, Oberon, Oberon-2, Active Oberon, Component Pascal, Mesa, Mesa/Cedar, Modula-2+, Modula-3, Eiffel, Basic,...

Although in Wirth inspired languages, actually the indexes are flexible, but by convention 1 gets used.

I had a job about 7 years ago doing Coldfusion and Flash. Coldfusion is 1 indexed and Actionscript is 0 indexed...this threw me off enough to the point of having a near-religious aversion towards explicit indexing, and while I've largely drunk the functional Kool-aid where I almost exclusively use maps and filters and reduce.

I really do with the 1 indexing had stayed around, since I feel like it's more natural to say the 1st element, instead of the 0th.

>> I really do with the 1 indexing had stayed around, since I feel like it's more natural to say the 1st element, instead of the 0th.

It's not the 0th element. It is the 1st element and has an offset of 0 from the beginning of the array.

Not saying it's better or worse, but that if you change the words you use to describe it, you may find it easier to use.

To my surprise, I just learned that ranges in Rust don't include the end number which felt incredibly stupid from a conceptual point of view (python too). But is syntactically useful when doing:

for x in 0..len(my_array) {

My preference would be that a range include the end number and the language provide more python-like iterators and list comprehensions. I am aware that there is a library that provides more python-like syntax, but that doesn't change the oddness of ranges in either language. I guess I just need to remember that the interval is open on one end. Which brings to mind the notion of using [0..n] or [0..n) in a language...

> It's not the 0th element. It is the 1st element and has an offset of 0 from the beginning of the array.

This is why I think the terminology should be "indexed arrays" and "offset arrays" (and variables perhaps even called index/idx/i or offset/ofst/o as appropriate) instead of using the terms "0-indexed" or "1-indexed."

But I have a hard enough time getting out of the habit myself, and some people are going to hate using o as a variable, so....

Python almost always does what I want.

If I say `for x in range(10)` it iterates exactly 10 times, starting at zero (which is convenient for 0-index lists in python). It would be extremely counter-intuitive if it did [0,10] as it would iterate 11 times. I agree though that it would be much less ambiguous if you could just do `for x in [0..10)`, for example.

Current implementation requires the least amount of "off-by-one" corrections for most tasks, IMO.

>> If I say `for x in range(10)` it iterates exactly 10 times

Right and I expect that. The issue I have is that the values do not include 10. It turns out great in Python and Rust where things are 0-indexed, but that does not change the fact that the range construct itself is strange in not including 10.

I'm sure the notion of using mathematical notation where [1..10], (0..10], [1..11), and (0..11) all mean the same thing would drive the language parsing people nuts. Mostly because some of those involve unmatched [) or (]. But that's why we have a computer right?

Rust actually has both [0..=n] is inclusive

https://doc.rust-lang.org/std/ops/struct.RangeToInclusive.ht...

>It's not the 0th element. It is the 1st element and has an offset of 0 from the beginning of the array.

It should be indexed with its position then a[1], as we do in all other aspects of life (and in math), and not with it's offset.

> as we do in all other aspects of life

You mean like elevators? You may be surprised to learn that elevators in America are 1-indexed (ground floor == floor 1), but in Europe they are 0-indexed (ground floor == floor 0).

As a European I'm not really surprised, but it's not exactly the same thing. It's not like the ground level is considered "the 0th floor" and thus we use 0-based indexing.

In most European countries the ground floor is not considered the same thing as the others. As Wikipedia puts it: "In most of Europe, the "first floor" is the first level above ground level".

We consider and count as floors the "layers" above the ground level. In french for example, the ground level is called "rez-de-chaussée" and the floors above it "XX étage". The ground level is not an "étage" (in American terms, the "ground level" is not considered a floor, and is not counted among the floors).

For this reason, apart from elevator labels nobody calls the ground level "the 0th floor" when speaking/writing.

And even in elevators, O is just used as a convenient way to convey the ground level (since the buttons don't fit much) -- and not everywhere. In many elevators it gets it own designation (e.g. G or GRD or some other national variety).

It's "the ground level" (with different names per country) + "N floors".

A multi-floor building with ground floor + 3 floors can even named "3rd-storey building" in some countries (and the ground level is just taken as granted) -- e.g. une maison à deux étages in the UK --> 3 story building in the US.

>> A multi-floor building with ground floor + 3 floors can even named "3rd-storey building" in some countries

I think you just refuted your own previous assertion that 1-indexing is universal in all other aspects of life.

Not sure what you mean. There are 3 floors (as europeans define a floor, ie. anything ABOVE what americans call ground floor) and are named floor 1, floor 2 and floor 3.

So, no 0-based indexing here.

We call the house a "3-storey house" not because we zero index, but because the cardinality of it's floors (as europeans define a floor) is 3. In "3-storey building" for Europeans, 3 is the "length", not the last index.

Ground floor, 1st floor, 2nd floor still sounds very much like 0-based indexing. Is the objection just that people don't literally say the word "zero", but instead say ground?

“Ground floor” is not the European name; the names are things like “Ground of the roadway” (literal word-by-word translation of the French name), “first floor”, “second floor”, etc.

It's no more zero-based indexing than naming relations as “sibling”,“first cousin”,“second cousin” is, just because some hypothetical culture that also uses 1-based indexing but counts siblings as first cousins might rationalize our system as starting with “zeroth cousins” where they have “first cousins”.

There are also differences of building styles, maybe this is part of how we ended up with different terminology. The prototypical Parisian building has a paved driveway to the courtyard which is on the ground level. The prototypical New England house has a first floor which is a wooden thing with floorboards, 3 feet or so above ground.

If I heard that in other countries their use of 1st floor was 1 off from me, and they had a name for whatever was before 1, then what they have is like a zero, especially if some elevators use the literal 0 to mean the ground floor.

>and they had a name for whatever was before 1

What they have merely names what Americans name as zero.

But it's not a stand-in for zero, for us, it's a different entity (a different thing).

A floor (etage, piano, orofos, etc) is a "layer of building where people live above the ground level layer".

So there's no zero-based indexing of floors, because the first item in the set of what are considered as floors is called "first" (e.g. primo in italian).

So, the thing one must understand before they say "same difference", is the other cultural difference: that most European countries don't consider the ground level "floor" to be a floor/story.

I.e, we don't consider the upper floors and the "ground floor" to be in the same set. Which is also why we don't count them when we say a "2 story house" (and we mean a house with 3 such layers, ground story + 2 stories).

Is there a zero-based indexing of the whole "heterogenous" set of ground level + floors?

Well, it's common to have the ground level designated with G or national specific names: BG, BV, E, IS, PB, PT, RC, S, P, PK, etc.

It's just that in some elevators 0 is a substitute for this -- which is probably due to the few common brands and parts being international and nobody bothering to change them (e.g. Otis). That's more a red herring than how Europeans think about floors or index them.

>> So there's no zero-based indexing of floors, because the first item in the set of what are considered as floors is called "first" (e.g. primo in italian).

So the floors are numbered according to their distance above the ground level (whatever that's called). This matches my suggestion of treating zero-based indexing as a distance from the first element.

>> Is there a zero-based indexing of the whole "heterogenous" set of ground level + floors?

Yes there is! It's how the elevator buttons are labeled with the possible variation of using a label instead of "0".

The European elevator numbering scheme according to your own comments matches more closely with a zero-based indexing scheme than a 1-based. Or more precisely it matches my proposal to consider the numbers used to reference array elements as distances rather than indexes.

I think you misunderstand how the European numbering works. Think of it like Europeans count the separations between levels. There is no 0th separation, the first separation is the ceiling above the ground level. Saying that the ground level is the "first element" is begging the question - this is just not what Europeans count. (Well some do, but then they count similar to Americans, there is still no 0th floor ether way).

It is true that some elevators label the ground level 0, but this is usually when there are also negative levels (cellars).

It's not zero-based indexing, it's measuring the distance from a reference level. That matches my suggested change in terminology for indexing quite nicely (for zero-based indexing).

Yup, for Europe I'd actually be curious which countries don't consider the first floor the one above the ground floor, since they're probably the minority.

It is not 0-indexed, it is just that "floor" means something different than in American English. It means a level above the ground. So the first level above ground is the first floor.

The German word Stockwerk is even clearer. It describes the wooden planks which separates two levels. So if you live on the first Stockwerk you live one level above ground.

0 based arrays is objectively the preferred way for me and not for historical reasons. I write a lot of low level graphics algorithm stuff, and 1-based arrays would complicate index arithmetic.

like now with everything 0 based having something like:

arr[offset1 * 32 + offset2]

would be the following if all my offsets would be 1-based and arrays would be 1-based:

arr[(offset1 -1) * 32 + offset2]

which is pretty arbitrary...

“Objectively preferred for me” sounds an awful lot like it’s subjective

Historically 0 based is for low level languages. 0 based makes sense for C.

My issue is higher level languages Python, Java, C# there is plenty of things that just are complicated and doing arrays off 0 is one of them. Doing data science or statistics just makes it obvious that you have two different sets on numbers. 1 doesn't mean the same thing in every instance in your programming and the functional programming side of me hates that.

You could reshape it (https://docs.julialang.org/en/v1/base/arrays/#Base.reshape). But if you're interfacing with libraries written with C interface you'd still have to subtract for both offset1 and offset2.

that may be your impression, because you dont know julia's powerful, no overhead indexing abstractions yet ;) i also write lots of graphics low level code, and i couldn't be more glad that i don't need to do those error ridden indexing calculations anymore, since they're simply not needed... note, that you can also seamlessly create new array types that store 0 indices into other arrays - and because of julia's great composability, i can make them work with my indexing agnostic algorithms while being 0 overhead compatible with opengl's memory layout :)

A ton more people do high level programming, than low level programming. You guys build the tools and many more people use them.

Dijkstra makes an interesting argument for 0 based indexing in EWD831.

https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/E...

For what it's worth mathematics is more than flexible enough to handle both 0 and 1 based indexing. Using 1 based just looks neater since you can count x_1, ..., x_n rather than x_0, ..., x_{n-1}. Sometimes both are used at the same time e.g. if you add an extra coefficient at the start rather than at the end, this happens particularly when dealing with wedge products where the parity of the new index matters.

Also it's usually a bad sign if you need to worry too much about what index you used, you might be better of using index sets with whatever structure you need (and only the structure you need). In program languages that support it generous application of ranges and generators tends to get rid of most complications.

VBA actually lets you decide at the top of each module whether to use 0 or 1 based indexing. The default value is 0, but you can specify "Option Base 1" to change that.

There is an interesting note in the Wikipedia page for "Dartmouth BASIC" which says the second edition "also allowed arrays to begin as subscript 0 instead of 1. This was especially useful for representing polynomials."

The issue is 1 will mean different things. That should be a bigger issue than anything else. When you are doing math

1 + 1 = 2 always means two. When you are getting the 1 column we are getting the second column. This while makes sense when doing certain lower level programming this makes no sense with functional or higher level programming.

+ Elixir:

Regex and Binary indexes are zero-based, List and Tuple are one-based

Are they, though? The relevant functions in Enum all seem to be zero-based, for example:

    iex> [:foo, :bar, :baz] |> Enum.at(1)
    :bar

Not that it really matters anyway. Like with Erlang, in the vast majority of cases where I'd normally reach for querying a list element by index, pattern matching is the better / more idiomatic option. Compare:

    foo = list |> Enum.at(0)
    bar = list |> Enum.at(1)
    baz = list |> Enum.at(2)
    rem = list |> Enum.slice(3..-1)

with:

    [foo, bar, baz | rem] = list

Both give you the exact same values of foo/bar/baz/rem, but the latter is arguably more readable and concise, and entirely avoids the 0 v. 1 debate.