Numbering should start at π (2025) (umars.edu)
For instance, when dealing with memory words, do u address the word itself or its starting location (the first byte)?
The same consideration applies to coordinate systems: r u positioning urself at the center of a pixel or at the pixel's origin?
Almost 2 decades ago I designed an hierarchical IDs system (similar to OIDs[1]). First I made it 0-based for each index in the path. After a while I understood that I need to be able to represent invalid/dummy IDs also, so I used -1 for that. It was ugly - so I made it 1-based, & any 0 index would've made the entire ID - invalid
---
The mix of "The same consideration applies to coordinate systems:" and "r u positioning urself..." in the same message is ridiculous to me and I can't take anyone seriously who speaks like this.
It's not illegal or immoral, but it is at the very least, demonstrably distracting from their own actual substantive point. Here we all are talking about that when they otherwise had a perfectly good observation to talk about.
Everyone is jumping on your use of the word "serious" as though you meant serious like cancer instead of just not texting ya bro bout where u at tonite, as though there are only two levels of formal and informal, the two extremes.
If this is so casual and we are txting, then why did they use punctuation and no emojis? Ending sentences with periods is verbal abuse now, so, I guess we're not txting after all? Pick a lane!
hardly. this is an informal internet forum of mostly anonymous people chit chatting about random stuff instead of working.
This could be what you're observing. Or perhaps they just like the aesthetics.
Like the sibling comment says, we're all semi anonymous internet folks talking about mostly not serious things.
I've never heard the distinction stated this way. It's clarifying.
It is, but it need not be. In the category of pointed sets with endofunctor, (Z_{\ge 1}, 1, ++) and (Z_{\ge 0}, 0, ++) are isomorphic (to each other, to (Z_{\ge 937}, 937, ++), and to any number of other absurd models), so either would do equally well as a model of Peano arithmetic.
The original formulation of Peano started at 1.
I never realized it was controversial. I think I've always included 0 in the nat numbers since learning to count.
But there are some programming books I've read, I want to say the Little Typer, or similar, that say "natural number" or "zero". Which makes actually confuses me.
Numbering should start at π (2025) (umars.edu)
My personal take is that we should not let one short sighted decision 1500 years ago to mess us up and the first century covers from years 0 to 99 and the 21 century 2000 to 2099
https://madeofrome.com/how-was-it-made/how-did-we-choose-the...
I have a database where I tried keeping once per year periodic events(like birthdays or holidays) as postgres intervals, so number_of_months:number_of_days_in_month past start of year or effectively 0 based month-day. this looks weird but solved so many calculation problems I kept it and just convert to more normal 1 based on display. and a shout out to postgres intervals, they do a heroic job at tracking months, a thankless job to program I am sure.
So Ordinal quantities represent the ordering of coordinates and can be negative, while Cardinal quantities describes the counting of magnitudes and must be positive.
You can transform between ordinal domains and cardinal domains via the logarithm/exponential function, where cardinal domains have a well-defined “absolute zero” while ordinal domains are translation-invariant.
The GP's explanation seems more fitting for the year 2000 ambiguity. Are you measuring completed years (celebrate millenium on NYE 2001) or are years the things happening between 0 and 1, 1 and 2, etc (celebrate on 2000, because we're already in the 2000th "gap")?
And BTW that ID system was used in the system processing PBs of data in realtime per day back in the early 2000s, so it’s not that it was super-inefficient.
In fact “natural numbers” is ambiguous, as it can both contain zero or exclude it depending on who uses it.
From a logical point of view I think it's totally unnatural to start at 1. You have 10 diffferent "chars" available in the decimal system. Starting at 1 mostly leads to counting up to 10. But 10 is already the next "iteration". How do you explain a kid, who's learning arithmetics, that the decimal system is based on 10 numbers and at the same time you always refer to this list from 1 to 10.
Also you use a circular reasoning.
They had a 6 x 6 grid with 26 letters, then the digits 1-9, then an extra X to fill in the space left over. :facepalm:
Upshot: if you take the above seriously (proposed by Kelly Boothby), the median proposed by Kelly-Bootle returns to the only sensible choice: zero.
In computer programming we often only need the position of the gap to the left, though, so calling it "the rail that starts at x=0" works. Calling it "the rail that ends at x=1" is alright, I guess, if that's what you really want, but leads to more minus ones when you have to sum collections of things.
At least we're not stuck with the Roman "inclusive counting" system that included one extra number in ranges* so that e.g. weeks have "8" days and Sunday is two days before Monday since Monday is itself included in the count.
French (and likely other Latin languages?) are not quite so lucky. "En 8" means in a week, "une quinzaine" (from 15) means two weeks...
If we're on a Tuesday, and I say we're meeting Wednesday in eight, that Wednesday is indeed 8 days away.
Now I'm fascinated by this explanation, which covers the use of 15 as well. I'd always thought of it as an approximation for a half month, which is roughly 15 days, but also two weeks.
To partially answer the other Latin languages, Portuguese also uses "quinze dias" (fifteen days) to mean two weeks. But I don't think there is an equivalent of the "en huit". We'd use "na quarta-feira seguinte" which is equivalent to "le mercredi suivant".
Most beginners still start out thinking in one scale at a time (except perhaps Guitar, which sorta has its own system that's more efficient for playing basic rock). So thinking about music as having 7 notes over a base "tonic" note, plus some allowed modifications to those notes, is still a very useful model.
The problem is that these names percolated down to the intervals. It is silly that a "second" is an interval of length 1. One octave is an 8th, but two octaves is a 15th. Very annoying. However, it still makes sense to number them based on the scale, rather than half-steps: every scale contains one of every interval over the tonic, and you have a few choices, like "minor thirds vs. major thirds" (or what should be "minor seconds vs. major seconds"). It's a lot less obvious that you should* only include either a "fourth" (minor 3rd) or a "fifth" (major 3rd), but not both. I think we got here because we started by referring to notes by where they appear in the scale ("the third note"), and only later started thinking more in terms of intervals, and we wanted "a third over the tonic" to be the same as the third note in the scale. In this case it would have been nice if both started at zero, but that would have been amazing foresight from early music theorists.
* Of course you can do whatever you want -- if it sounds good, do it. But most of the point of these terms (and music theory in general) is communicating with other musicians. Musicians think in scales because not doing so generally just does not sound good. If your song uses a scale that includes both the minor and major third, that's an unusual choice, and unusual choices requiring unusual syntax is a good thing, as it highlights it to other musicians.
Yes, we are. C gives pointers one past the end of an array meaningful semantics. That's in the standard. You can compare them and operate on them but not de-reference them.
Amusingly, you're not allowed to go one off the end at the beginning of a C or C++ array. (Although Numerical Recipes in C did it to mimic FORTRAN indices.) So reverse iterators in C++ are not like forward iterators. They're off by 1.
[1] https://devblogs.microsoft.com/oldnewthing/20211112-00/?p=10...
Nelson Elhage wrote about an alternate interpretation: https://blog.nelhage.com/2015/08/indices-point-between-eleme...
first, second, twoth, third, fourth, ...
or shortened:
0st, 1nd, 2th, 3th, 4th ...
Where is the first item? Slot 0. How much space does one item take up* (ignoring administrative overheads)? The first and only item takes up 1 space.
It isn't usual for me to agree with the mathematical convention for notations, but the 1st element of a sequence being denoted with a "1" just seems obviously superior. I'm sure there is a culture that counts their first finger as 0 and I expect they're mocked mercilessly for it by all their neighbours. I've been programming for too long to appreciate it myself, but always assumed it traces back to memory offsets in an array rather than any principled stance because 0-counting sequences represents a crazy choice.
Assuming `a` is the address of the beginning of the array, the 0-based indexing on the left is equivalent to the memory access on the right (I'm using C syntax here):
a[0] == *(a + 0)
a[1] == *(a + 1)
a[2] == *(a + 2)
...
a[i] == *(a + i)
a[1] == *(a + 1 - 1)
a[2] == *(a + 2 - 1)
a[3] == *(a + 3 - 1)
...
a[i] == *(a + i - 1)
> but always assumed it traces back to memory offsets in an array rather than any principled stance because 0-counting sequences represents a crazy choice.
So you claim this is just an appeal to authority and as a rebuttal you give appeal to emotion without being an authority at all?
> the 1st element of a sequence being denoted with a "1" just seems obviously superior
> I'm sure there is a culture that counts their first finger as 0 and I expect they're mocked mercilessly for it by all their neighbours
> 0-counting sequences represents a crazy choice
5G chess move.
Zero based indexing had nothing to do with Dijkstra's opinion but the practical realities of hardware, memory addressing and assembly programming.
> I'm sure there is a culture that counts their first finger as 0
Not a one because zero as a concept was discovered many millenia after humans began counting.
Also, the origin is at 0, not at 1. If you begin at 1, you've already moved some distance away from the origin at the start.
Besides, in the rare cases where it does matter you're free to pick whichever is convenient.
arr[(i++ % arr.length)] = foo;
arr[(i++ % arr.length) + 1] = foo;
I'll concede that it's not all that significant as a difference, but at least IMO it's nicer.
Also could argue that modular arithmetic and zero-based indexing makes more sense for negative indexing.
last := vector[vector-length(vector)];
last := vector[vector-length(vector) - 1];
To me this is a far more compelling argument for 0-based indexes than anything I've seen in favor of 1-based indexes.
e.g.
type Index is range 1 .. 5;
type My_Int_Array is
array (Index) of My_Int;
DIM X(5 TO 10) AS INTEGER
S (S'First), S (S'First + 1), S (S'First + 2), …, S (S'Last)
So effectively, indexing is zero-based for most code.
At least in standard Pascal arrays with different index ranges were of different incompatible types, so it was hard to write reusable code, like sort or binary search. The solution was either parameterized types or proprietary language extensions
So to be clear, we have to tediously specify "z e r o - b a s e d " or "o n e - b a s e d" every single time to avoid confusion. (Is there a chance for creating some new, terser consensus here?)
- Offset: 0-based
- Index: 1-based
For example, in music we use numbers for the notes of a scale (G is the 5th of C, because in the C major scale: C=1, D=2, E=3, F=4, G=5, A=6, B=7). The numbers are clearly indices for the notes of the scale.
But we often think of stuff like: what's the 3rd of the 5th -- that is, get the note at the 5th position (G in our example) and then get the 3rd of that note (the 3rd of G is B). But note that B is the 7th of C major, not the 8th you'd get from adding 5 and 3.
The problem, of course, is that we ended up using the numbers as offsets, even though they started as indices.
I can suggest "z8d" and "o7d" otherwise. (/jk)
for (i=N-1; i>=0; i--)
for (unsigned i = N - 1; i < N; --i)Personally, I find that in compiler writing, which is the only programming I do these days, the only things I use indexes for are line numbers and character offsets into strings. Calling the first character the zeroth character is ridiculous to me, so I just store a leading 0 byte in all strings and then can use one based indexing with no performance hit. Alternatively, since I am the compiler writer, I could just internally store the pointer to the string - 1 to avoid the < 1 byte per string average overhead (I also machine word align strings so often the leading zero doesn't affect the string size in memory).
If you are often directly working with array indices, you are likely doing low level programming. It is worth asking if the task at hand requires that, or if you would be better off using higher level constructs and/or a higher level language. Low level details ideally should not leak into the application level.
Try to count 4 seconds, if you start at 1 you messed up. Babies start at 0 years old. Etc..
I do agree it's a convention though. Months and years start at 1, but especially for years, only intervals are meaningful, so it doesn't really matter what zero is (even though christ is totally king)
Start from 0 if you are counting boundaries (fenceposts, memory addresses)
Start from 1 if you are counting spaces (pages in a book, ordinals)
Floors are a case where both make intuitive sense, which is maybe how we ended up with European vs American floor numbering.
* Start from 0 if you are indexing. I.e. you are identifying an item or its position.
* Start from 1 if you are counting. I.e. you are saying how many items there are.
It doesn't matter what it is. I don't know why you think pages in a book are somehow different to memory addresses.
The mark on your measure tape corresponds to the total sum/amount.
If you count from zero, number of elements no longer corresponds to the size/length. So already here you deviate away from your tape principle.
You have one whole element when your tape measure shows 1, not zero.
I notice almost all defenses of 1-based indexing are purely based on arbitrary cultural factors or historical conventions, e.g. “that’s how it’s done in math”, rather than logical arguments.
You have lived zero full years and are in the first year of your life. In most (but not all) countries the former is considered "your age".
That's consistent with both zero-based and one-based indexing. Both agree on cardinal numbers (an array [1, 2] has length 2), just not on ordinal numbers (whether the 1 in that array is the "first" or "zeroth" element).
> I notice almost all defenses of 1-based indexing are purely based on arbitrary cultural factors or historical conventions, e.g. “that’s how it’s done in math”, rather than logical arguments.
I think it's largely a matter of taste in either direction. But, I'd raise this challenge:
arr = ['A', 'B', 'C', 'D', 'E', 'F']
slice = arr[3:1:-1]
print(slice)
Personally I feel like I have to go through a few steps of reasoning to reach the right answer - even despite having almost exclusively used languages with 0-based indexing. If Python were instead to use MatLab-style indexing (one-based, inclusive ranges), I could immediately say ['C', 'B', 'A'].
I think whenever people say "zeroth" they speak in jest and doubt that there is any disagreement on the fact that the element without predecessor (nowadays in programming most often assigned index 0) is the first element.
You used "first" in that sense naturally just in the sentence before without the slightest notion of ambiguity.
You have lived zero full years and are in the first year of your life.
What people wrongly get riled up with is the fact that ordinal (first) is not in sync with the cardinal (index 0), but it rarely is anyways. If you go to an administrative office and pull your number 5357 no one assumes that there are 5356 people in the queue before them. Your are still the 5th or 10th in line, even if your index is 5357.
Consider the following from the Irish Constitution:
> 12.4.1° Gach saoránach ag a bhfuil cúig bliana tríochad slán, is intofa chun oifig an Uachtaráin é.
and the official translation to English:
> 12.4.1° Every citizen who has reached his thirty-fifth year of age is eligible for election to the office of President.
For those unfortunate few who do not understand Irish, that version says "Every citizen who is at least thirty-five years old", whereas the translation should in principle (arguably) allow a thirty-four-year-old.
Luckily the Irish version takes precedence legally. A constitutional amendment which would have lowered the minimum age to 21 and resolved the discrepancy was inexplicably rejected by the electorate in 2015.
Typically 3 months shy of 1 year, so about 0.75.
For human cultural purposes, you are 0 days old at the time and date recorded for your birth. It goes on your birth certificate. If you find a culture that celebrates conceptiondays and issues conception certificates, let me know.
If it helps: you have one whole array element only if one year has passed
What are you trying to do: do you want to know where each element starts, or do you want to measure the total sum/accumulated amount?
So, it depends on what you understand as "numbering". If it is about counting objects, the word "first object" refers to existence of non-zero number of objects. This shows why the first one can't be called as zero, as zero is not equal to non-zero.
If the numbering is about continuous scale such as tape measure, then the graduations can start with zero. But still the first meter refers to one meter, not zero meters.
It looks silly when people have their book chapters numbering to begin with zero. They have no clue whether the chapter refers to a span or a cut. Sure, they can call the top surface of their book cover as zero, though. But still they can't number a page as zero.
The use of zero index for memory location comes from possible magnetic states of array of bits. Each such state is a kind of a cut, not a span. It's like a graduation on the tape measure, or mile stone on the side of the road. So it can start with zero.
So, if you are counting markers or separators, with zero magnitude, you can start at zero. And when you count spans or things of non-zero magnitude, you start at one. If you count apples, start at one. If you count spaces between apples start at zero.
Behold, the really stupid things you can do in Javascript:
let myArr = [];
let index = 0;
myArr[--index] = 5;
console.log(myArr.length); // 0
console.log(myArr[index]); // 5I recently picked up Lua for a toy project and I got to say that decades of training with 0-based indexes makes it hard for me to write correct lua code on the first try.
I suppose 1-based index is more logical, but decades of programming languages choosing 0-based index is hard to ignore.
Yes - many file formats also work with zero-based indices, not to mention the hardware itself.
One-based indexing is particularly problematic in Lua, because the language is designed to interoperate closely with C - so you're frequently switching between indexing schemes.
I wouldn't say it's more logical. More intuitive perhaps.
It just matches the convention used in the language that one has learned as a child, so one is already familiar with it.
The association between ordinal numbers and cardinal numbers such that "first" corresponds to "one" has its origin in the custom of counting by uttering the string "one, two, three ..." while pointing in turn to each object of the sequence of objects that are counted.
A more rigorous way of counting is to point with the hand not to an object, but to the space between 2 successive objects, when it becomes more clear that the number that is spoken is the number of objects located on one side of the hand.
In this case, it becomes more obvious that the ordinal position of an object can be identified either by the number spoken when the counting hand was positioned at its right or by the number spoken when the counting hand was positioned at its left, i.e. either "0" or "1" may be chosen to correspond to "first".
Both choices are valid and they are mostly equivalent, similarly to the choice between little-endian and big-endian number representation. Nevertheles, exactly like little-endian has a few advantages for some operations, so eventually it has mostly replaced big-endian representations, the choice of "0" for "first" has a few advantages and it is good that it has mostly replaced the "1 is first" convention.
For people who use only high-level programming languages, the differences between "0 is first" and "1 is first" are less visible, exactly like the differences between little-endian and big-endian. In both cases the differences are much more apparent for compiler writers or hardware implementers.
Besides "1 is first" vs. "0 is first" and little-endian vs. big-endian, there exists another similar choice, how to map the locations in a multi-dimensional array to memory addresses. There is the C array order and the Fortran array order (where elements of the same column are at successive addresses).
Exactly like "1 is first" and big-endian numbers match the conventions used in writing the European languages, the C array order also matches the convention used in the traditional printed mathematical literature.
However, exactly like in the other 2 cases, the opposite convention to the traditional written texts, i.e. the Fortran array order is the superior convention from the point-of-view of the implementation efficiency. Unfortunately, because much less people are familiar with the implementation of linear algebra than with the simpler operations with numbers and uni-dimensional arrays or strings, so they are not aware about the advantages and disadvantages of each choice, the Fortran array order is used only in a minority of programming languages. (An example of why the Fortran order is better is the matrix-vector product, which must never be implemented with scalar products as misleadingly defined in textbooks, but with AXPY operations, which are done with sequential memory accesses when the Fortran order is used, but which require strided memory accesses if the C order is used. There are workarounds when the C order is used, but with the Fortran order it is always simpler.)
0 1 2 3 4
-----------------
| A | B | C | D |
-----------------
-4 -3 -2 -1 -0
Why?
How do you number things in real life? If you have two options, do you number them "option 0" and "option 1" or "option 1" and "option 2"? If you create a presentation with numbered bullet points, do you start numbering them from 0 or 1?
1. This is my first point
2. This is my second point
Outside of programming, even most programmers use zero-based indexing only when they're making a programming joke.
Zero-based indices create odd effects even in programming, although we don't really notice them anymore.
Consider:
$array := ['a','b','c']
for($i:=0; $i<3; $i++) {
echo($array[$i])
}
[0,1,2) + [2,3,4) = [0,1,2,3,4)
meanwhile
[0,1,2] + [2,3,4] = [0,1,2,2,3,4] — this double counting is just ugly
What about the range 0 < i ≤ N which starts with 1? Why only use ≤ on the lower end of the range? This zero-based vs one-based tends to come up in programming and mathematics, and both are used in both areas. Isn't it obvious that there is no universally correct way to index things?
I would note that the argument is weakened when you look at the later bound, since you have the same problem there, it's just more subtle and less commonly encountered -- yet it routinely creates security bugs!
It's because we don't work with integers, we work with fixed-size intervals within the set of integers (usually a power of two consecutive integers). So `for (i = 0; i < 256; i++)` is just weird when you're using 8-bit integers: your upper range is an inexpressible value, and could easily be compiled down to `for (i = 0; i < 0; i++)` with two's complement, eg if you did `uint8_t upper = 256; for (uint8_t i = 0; i < upper; i++)`. That case is simple, but it gets nastier when you are trying to properly check for overflow in advance and the actual upper value is computed. `if (n >= LIMIT) { return error; }` doesn't work if your LIMIT is based on the representable range. Nor does `if (n * elementSize >= LIMIT) { return error; }`. Even doing `limit = LIMIT / elementSize; if (n >= limit) { return error; }` requires doing the `LIMIT / elementSize` intermediate calculation in larger-width numbers. (In addition to the off-by-one if LIMIT is not evenly divisible by elementSize.)
So when dealing with overflow checks, 0 ≤ i ≤ N may be better. Well, a little better. `for (i = 0; i <= LIMIT; i++)` could easily be an infinite loop if LIMIT is the largest in-domain value. You want `i = 0; while (true) do { ...stuff...; if (i == LIMIT) break; i++; }` and at that point, you've lost all simple correspondence with mathematical ranges.
> Isn't it obvious that there is no universally correct way to index things?
I don't know about "obvious", but I agree that there is no universally correct way to index things.
"The above has been triggered by a recent incident, when, in an emotional outburst, one of my mathematical colleagues at the University —not a computing scientist— accused a number of younger computing scientists of "pedantry" because —as they do by habit— they started numbering at zero. "
:')
You see zero in elevators all the time.
You could argue it's a bit of a translation error. The French and German words for floor are referring to ways to add platforms above ground. Either by referring to walls, wooden columns or floor joists. Over the course of language evolution those words have both broadened and specialized, referring to building levels in general. But the way they are counted still reflects that they originally refer to levels built above ground. The English "floor" on the other hand counts the number of levels that are ground-like, which naturally starts at the actual ground.
I have Ar apples for sale.
Only $A.J each!
Languages aimed at casual audiences (e.g. scripting languages like Lua) should maybe just provide two different ways of indexing into arrays: an `offset` method that's zero-indexed, and an `item` method that's one-indexed. Let users pick, in a way that's mildly less confusing than languages that let you override the behavior of the indexing operator (an operator which really doesn't particularly need to exist in a world where iterators are commonplace).
All of these design features seem to be helpful to casual programmers and are common in languages and programming environments designed for them, such as BASIC, Smalltalk, sh, Python, Tcl, and Microsoft Excel.
pansa2's comment https://news.ycombinator.com/item?id=43435736 also has a citation to Ierusalemschy, who said in https://old.reddit.com/r/lua/comments/w8wgqb/complete_interv...:
> And at that time, the only other option would be Tcl, "tickle.” But we figured out that Tcl was not easy for nonprogrammers to use. And Lua, since the beginning, was designed for technical people, but not professional programmers only.In the beginning, the typical users of Lua, were civil engineers, geologists, people with some technical background, but not professional programmers. And "Tcl" was really, really difficult for a non-programmer. All those substitutions, all those notions, etc. So we decided to create a language because we actually needed it.
(Tcl, of course, was designed for chip designers.)
"one of the design goals, was for Lua to be easy for nonprogrammers to use"
[1] https://www.reddit.com/r/lua/comments/w8wgqb/complete_interv...
- statements dreamed up by the utterly deranged.
They have played us for absolute fools.
Computer memory.
This discrepancy appears in physics too. It's common to use 1,2,3 for spatial indices, but when you reach enlightenment and think in terms of spacetime you add a zero index and not a four.
but good point, remembering academic linear algebra, seeing 0..n-1 in sigma/sums notations would be not convenient
It settles the discussion of array numbering. F*ck off Visual Basic, MS Javascript, and all the languages that said you should start with 1.
Array(1...5) == [1,2,3,4,5]
Array(1..<5) == [1,2,3,4]"LISP has jokingly been described as “the most intelligent way to misuse a computer”. I think that description a great compliment because it transmits the full flavour of liberation: it has assisted a number of our most gifted fellow humans in thinking previously impossible thoughts."
This is obviously a compliment; it even mentions that word.
Even a less positive remark than this would still be resounding compliment from a computer scientist who said things such as that BASIC causes irreparable brain damage!
So count this as a piece of evidence that he liked Lisp.
Lisp emphasizes structured approaches, and from the start it has encouraged (though not required) techniques which avoid destructive manipulation. There is a lot in Lisp to appeal to someone with a mindset similar to Dijkstra.