Hacker News Reader

Comment by fluidcruft | Hacker News Reader

I used to use it a lot, but the python libraries are much further ahead at this point. For my uses (essentially image processing and statistics) Octave is always playing catchup with Matlab but python is mostly at par or ahead of Matlab. With the exception of the parallel stuff... but that wasn't anything Octave had either. Eventually when I need performance again I'll see about figuring out how to migrate parts to Julia. One thing I like about the python things is there are some hints of IDL in there (I'm a masochist and liked IDL... Matlab frustrates me at times). Matlab was great for slapping quick UIs together and making little tools, but Jupyter works well enough for that.

The 0 indexing in python does really and truly suck sometimes though.

View on HN

> The 0 indexing in python does really and truly suck sometimes though.

Now that's something you usually don't hear. At my university I heard a bit of "urban legend" about how back in the day (think early 1990's) a couple of professors got a peer-reviewed article published because they found out that Matlabs 1-indexed implementation of some algorithm resulted in numerical errors, which they measured and corrected. Don't really remember the details, and most of those involved have already retired.

What you've said isn't surprising.

The problem isn't whether 0 or 1 are "right" or not, it's the inconsistency. It makes transcribing something from a textbook harder, because the indexing logic in a textbook algorithm can get quite intricate. It's even worse if they use slices like M[i:j,m:n].

Indexing from 1 is the standard in many areas, going back many decades. SWEs have adopted a different convention.

but this depends a lot on the particular formula. For example, if you use discrete Furier transforms, all formulas are natural with 0-indexing, but weird with 1-indexing. In general, when the indices of an array are to be interpreted as modulo N, you want them to be 0, 1, ..., N-1

It is inevitable to have to use both conventions if you do varied math stuff. Thus, you will never be happy.

The pragmatic solution for transcribing is probably to make some functions `array_index` and `array_slice` that automatically convert between the two conventions. I think Julia offers another way: It lets you choose between them.

I prefer OPTION BASE {0, 1} :)

(Obligatory) There are only 2 hard problems in computer science: cache invalidation, naming things, and off-by-one errors

may You concurrency forgotten have.

It just printed out in your comment a few hours after I thought I invoked it.

I just never find myself working out formulae/series/proofs on paper using zero-indexing. When you look up derivations/solutions in books and references they're one indexed. A recent example was a formula that had a (n-1)!*n! term that made sense from understanding the derivation. But I forgot to code it as (n-2)!*(n-1)! at first.

So you end up having to translate from one-indexed derivations to zero-indexed code and it leads to different bugs. Ultimately zero-indexing just trades one layer of bugs for another.

IMHO zero-indexing makes sense to people thinking about the machine, not necessarily the work people are trying to use the machine to do.

To be fair sometimes the opposite is true and zero-indexing gives less complex expressions.

There are good reasons why indexing from zero with exclusive upper bounds should be preferred. I'll defer to Dijkstra for the explanation: https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/E...

Because it's intuitive that an array contains an element before the first element?

Is this a pithy response? The first element is indexed by zero.

Isn't dropping Dijkstra links as an appeal to authority about 0-indexing considered a pithy response?

How about I drop a link about Einstein Notation with a curt observation that there are good reasons it uses both zero and one indexing simultaneously?

As I said it depends on how you are thinking about things. Indexing makes sense to people who are focusing only on the machine.

We're discussing programming language design. Referencing a prominent computer scientist to explain something on that subject better than I can seems like a reasonable thing to do. If you want to point me to somewhere where it can be argued that indexing from one is useful (not just a matter of aesthetics), please do.

Again, machines are not the purpose of computing.

"The purpose of computing is insight, not numbers." (Hamming)

Machines and notation are both tools. Aesthetics do matter particularly for tools used for thought.

There is no correct answer and imposing one tool's limitations on everything is not useful. Particularly not "just because Dijkstra said so".

Sometimes 0-indexing works well. Sometimes it sucks. Sometimes 1-indexing works well, sometimes it sucks.

I did in fact give you a reference. The fact that it's irrelevant to you and dismissed as merely "aesthetics" and that you think a computer scientist is the domain expert of all science tells me everything that needs to be said--you never deal with questions of correctness beyond mere transcription.

What I said is that moving from Octave/Matlab to python's zero indexing sometimes does truly suck. And I mean it. That doesn't mean 1-indexing never sucks or that I am inaware of Dijkstra's opinions. Having to arange(1, N+1) or 1:N+1 or whatever everywhere isn't eliminating off-by-one errors.

Matlab and Octave and FORTRAN etc are domain languages designed for linear algebra. They are of course going to be more convenient for their domains.

In language design, a choice is necessary. You can support all possible indexing strategies, but that's problematic for a whole different set of reasons. So you need to choose, index from 1 or from 0. I've never once thought my algorithmic implementation is mucky because of the index from zero, inclusive lower bound, exclusive upper bound policy languages. I used to regularly lament how ugly the MATLAB code was for that reason. Unless MATLAB had bolted on another language feature to solve that problem, I'll let my extensive (albeit 15 years old) use of MATLAB in signal processing algorithm implementation be my aesthetic guide.

I'm not here to defend Matlab as some aesthetic language (in fact why on earth they haven't poached more of Octave's syntax improvements remains an eternal mystery) so if you just want to bitch about Matlab go right ahead ;)

The scars run deep.

I have a ruler. What number does the first centimeter start at?

It's a bit like all those people claiming that the new millennium shouldn't have been celebrated until 2001. They didn't stop to think how many years pass between the epoch and the time of interest. You celebrate a baby's first birthday after one year of time has passed. Until that point they are zero (and a bit) years old.

Do you typically measure sets with a ruler?

Furthermore it depends on what you're doing with that first centimeter. In many instances the first centimeter is correctly considered to be 0.5

That's not a scientific paper.

I find it easier not to make mistakes when I index from 1.

It's a numbered manuscript by Edsger Wybe Dijkstra, one of the most influential members of computing science’s founding generation [1].

The issue stems from the word "index" in the sense of "to count" .. that the first cell is numbered 1 makes sense to some.

What is actually happening is measurement, or the offset from the origin of memory.

The first inch starts at zero on the tape measure and ends at 1, that first inch has an offset of zero.

For all manner of reasons to do with measuring memory as one might measure wood a great many people think in terms of memory offsets.

[1] https://www.cs.utexas.edu/users/EWD/

[redacted]

Maybe work on your communication skills.

The 1-based indexing in Matlab does truly suck, all the time.

The 0 indexing is something one can get used to. On the other hand the fact that range(k,n) goes from k,...,n-1 is the most annoying part.

That's so that range(10) has 10 items in it.

Yes. But when I use invoke range(k,n) or list[k:n] I intend to do operations on some specific items, not repeat some operations 10 times.

So every time I see `for i in range(10)`, I have to do the mental computation: I am repeating this operation on numbers from 0,...,9.

I would rather write `for i in range(9)` and know that I am operating on 0,..,9.

For anyone that spends significant time using these languages, those mental mappings are as natural as the one you seem to think is obvious - then the additional advantages of the approach become apparent.

Exclusive upper bounds mean slices work neatly: a[0:10], a[10:20], a[20:30] etc. That's very neatly represented in a loop from zero in steps of ten. That pattern turns up all over the place when accessing arrays.

I've spent enough time in MATLAB to have been scarred by that kind of array slicing and off-by-one errors.

This has the nice advantage that range(k,n) + range(n,m) == range(k,m).

Reply on news.ycombinator.com