[thunk]

1) MAXINT is already a special case, so testing inclusively doesn't introduce extra accidental complexity.

2) If you test the upper bound inclusively, then the upper bound of the previous subseq is not the lower bound of the next subseq.

3) I misinterpreted GP. Scratch that :)

[BillGoates]

1) I think you are missing the point. According to Dijkstra you need to test if a var is within a range with i < last + 1. If last = maxint your computer will explode.

2) Sorry, I don't have a clue what you mean. What's the difference between tests on subseqs from 0 or 1 based arrays?

[thunk]

1) I get it. If your array is that big you already have code dealing with array indices approaching MAXINT. Since it's already a special case it's not introducing extra complexity to change your test in that one place.

Edit: When I say "test it inclusively" I mean when last==MAXINT you test i<=last rather than i<last+1. It's a special case.

2) I was assuming the upper bound in your 1-indexed array was inclusive, since it's necessary for your previous point. If that's the case, then when iterating over subseqs you can't just assign the previous upper bound to the next lower bound. That situation occurs frequently, and Dijkstra mentions it in the memo.

[BillGoates]

1) The maxint was just an example and these tests are not limited to arrays. For the same I was talking about bytes. And comparing a byte value against 255 + 1 is still wrong.

So yes, test inclusively, but not only the special cases, but always. It will prevent bugs, make code more readable and give faster code,

Only it's not what Dijkstra advocates.

2) When iterating 20 <= i < 30 or 20 <= i <= 29 the result is the same. At the end of the loop i will be 30, so in both cases the next lower bound = previous upper bound + 1.

While typing I thought of a case where inclusive might be more confusing, When iterating to first + n. Then < would be better than <= first + n - 1.

But I think this has little to do with if 0 or 1 based arrays are better. Only the start is different, after that it's all the same.

[thunk]

1) I'm going to leave this one here, because I think we might be having a semantic disconnect.

2) ... the result is the same.

Ahh, but it's not. When looping over consecutive subseqs, i's scope is the inner loop, and you lose i's value on exit, which means you can't use it as the next outer loop's lower bound. The previous upper bound in your example is 29, but we want 30, which means we're back to index-jockeying. This is the common situation Dijkstra was referring to.

Regardless, I've enjoyed the back and forth with you. You may come back with a devastating rebuttal, but I've got to keep working. Until next time! :)