An example from my field: in financial modeling the typical pattern is to calculate an initial cash flow followed by further projected cash flows at fixed intervals (e.g., monthly). The natural way to store a series of cash flows (besides as a column in Excel) is just as an array, and if that array is 0-indexed, the index represents each cash flow's offset from the initial cash flow. This is both more natural and more convenient for lots of calculations - e.g., when calculating the net present value the number of discounting periods for each cash flow is just its index in the array.

I haven't encountered a code base that uses non-default array indices, but it sounds like a serious anti-pattern, especially if you're just changing from 1-based to 0-based.

Somehow I missed this comment. But as michaelcampbell wrote, in Ada you'd select the range that made sense for your application.

So if your application makes sense with 0-based (time series in your example) then you can do it:

  Cash_Flows : array (0..max_time) of Double;

It may even make sense to go negative for some things. For instance:

  Object_at_Altitude : array (-100..1000) of Object;

Or characters:

  Selected_Answers : array (range 'a'..'z') of Boolean;

Or a type that you've created:

  type Color is Red, Green, Blue, Yellow, Orange;
  Histogram_of_Colors : array (Color'Range) of Natural;

But a particularly nice thing is that arrays in Ada, unlike C, don't lose their size, so you can always do:

  for I in Cash_Flows'Range loop
    Some_Function(Cash_Flows(I));
  end loop;

So really the index never even has to be directly touched or known after creation.

The Julia translations of these might look as follows:

    using OffsetArrays
    
    cash_flows = zeros(0:max_time)
    
    altitude = zeros(Bool, -100:100)
    
    for I in eachindex(cash_flows)
        some_function(cash_flows[I])
    end
    # or in this case avoiding indexing:
    for cf in cash_flows
        some_function(cf)
    end
    foreach(some_function, cash_flows)

OffsetArrays is not quite a standard library but it's close. A lot of library code will work like this, calling `eachindex` or `axes` so as to be indifferent to how the arrays are indexed, and to pass this behaviour through to outputs as appropriate.

Thanks. I'll be taking a look a that for my code. I probably won't use this extensively, but it is a feature I have found useful in Ada (though I'm only a hobbyist, I gave up on convincing work to use it). I'm still a novice with Julia, but I'm doing some math heavy code and started exploring it for its relative ease of use (REPL, fast execution after compilation, ergonomics-focused language design).

> I haven't encountered a code base that uses non-default array indices,

If you're referring to <parent>'s mention of Ada with arbitrary ranges of indices, that's less about thinking of them as array indices and more of "a range of indices that make sense for your domain". Thinking about your problem in your problem's space rather than "how would my computer think of this"; making the map more like the territory, as it were.

I believe Julia lets you do this, although I'm not sure about the ease or generality of it.

Apparently you can [0]. However, it seems (in my first reading) to be something I'd avoid because it sounds like the "natural" way to code in Julia is to assume 1-based and you're likely to run into issues with libraries if you try and do anything else.

[0] https://docs.julialang.org/en/v1/devdocs/offset-arrays/

Julia is all about generic programming. There is a ton of support for offset arrays and people almost always try to support that style.

I stumbled a few times while reading binary data from a file in a 1-based language while I was using a hex editor (0-based) to view the same file. I don't think it proves one way is better than the other, but I suspect it's the common stumbling block that keeps the argument going.

If I'm not mistaken, Lua let's you assign any key (index) you want.

Lua's arrays/tables are more like hash tables, with an ability (still true? been a while since I've done anything with Lua) to optimize if you use a contiguous range starting at 1 for the key. But yes, you can use an arbitrary key.

Still true.

(lets not let's)

> Can someone show me a use case other than trying to cycle over the same data (EDIT: or range) repeatedly where 0-based is fundamentally better than 1-based? I mean, that's the only case I can think of where 0-based is actually going to be easier and more sensible.

Perhaps the canonical treatise on this subject: "Why numbering should start at zero". E. W. Dijkstra, 1982.

https://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF

I actually had that in my first draft of my comment. But I hadn't read it in a while and just did.

While he endorses 0-based in one of the remarks, he's actually endorsing the notational format of:

  a <= x < b or [a,b)

Where if b is renamed N, the length of a vector/array/list, in a 0-based notation, then you'd describe a 0-based vector's range as [0,N). The reasons he gives for preferring this notation for ranges (not, strictly, for 0-based ranges, but for all ranges):

1. Experience at Xerox where this notation (versus the other 3 he describes) leads to fewer errors. An informal study but a study none the less.

2. Using either [a,b) or (a,b], the size of the range is the difference between the provided bounds.

3. Using [a,b), adjacent ranges can be detected where b_1 = a_2. Given ranges [2,13) and [13,20) you can see that they're adjacent by just comparing two values. This certainly makes it quick to visually inspect as a code reader/writer. (the same argument can be made for (a,b])

4. An argument for either [a,b) or [a,b] is that the lower bound should be described by the minimum number in the range because it's more aesthetically pleasing.

So by process of elimination, he's left us with [a,b) as the better notation of the 4 options.

Based on an aesthetic argument, if you accept the above, then 0-based makes more sense because [0,N) is more aesthetically pleasing than [1,N+1). But if you use notation (c) from his report:

  a <= x <= b or [a,b]

Then 1-based can be described as the interval [1,N] where N is both the last element and the length of the vector/array/list. Which seems rather pleasant/natural to my eyes and fingers as well.

----------

If we accept the experience at Xerox, then his argument for 0-based indices is reasonable based on the assumption that ranges should be described as [a,b). If we don't accept it, then his argument is mostly based on aesthetics. That is, it's more pleasant to do a computation like:

  range size = b - a

than (for ranges described with [a,b]):

  range size = b - a + 1

And it's more pleasant to do a comparison like:

  adjacent? b_1 = a_2

than (for ranges described with [a,b]):

  adjacent? b_1 = a_2 - 1

But that first case doesn't matter in a 1-based array because the range size is just `b`, it's already stated in the range and there's no need for computation (just as it's present in 0-based ranges). Now, if your language permits arbitrary ranges then I think a case could be made for his suggested [a,b) notation. But if you're only choosing between 0-based or 1-based, I don't find it persuasive. It's still a tossup for me, neither is better than the other unless you also choose his notation for describing ranges, where [1,N+1) would be awkward but [1,N] is easier to use and understand.

> Then 1-based can be described as the interval [1,N] where N is both the last element and the length of the vector/array/list.

Doesn't work when the start position isn't 1.

> But that first case doesn't matter in a 1-based array because the range size is just `b`

Only if a = 1.