Some people spend too much time overthinking simple concepts...
Indices Point Between Elements
21–30 of 66 posts
Re: Indices Point Between Elements
#22I've found this a helpful way of explaining ranges in Python to students, it also makes Python's negative indices understandable for the same reason.
But it is contextual. When it comes to languages like C, where arrays are more directly mapped to pointers and memory layout, I've found it better to talk about pointers, and allow people to derive the behavior that way.
Either way, I'd be careful of trying to claim that 'this is what it is', rather than 'here is a way to remember it'.
Re: Indices Point Between Elements
#23Ugh. Please no. This only adds to the confusion, as now there are 2 ways in which indices can be interpreted.
also this works only in this special case of array being one sized. an index is an offset to a pointer in memory, shifted by the size of the structure it points to. there is no other way around, no magic tricks about index being between elements. of course people never exposed from c miss out all of this, and then are left to made up bullshit about how stuff actually works array index are offset to a memory location,…
Memory addresses are exactly analogous to array indices, and suffer from exactly the same semantics issues. After all, low-level memory is just an array of bytes.
We do have a convention that dereferencing a memory address returns the 8 bits to the right of that address. We've even optimized our hardware for that convention. But that's just a convention of the dereference operation; it's not fundamental to the addresses themselves.
I agree that a C pointer isn't analogous to an array index; that's because a pointer is a range, determined by a pair of memory addresses. One, stored at runtime, refers to the location before the first byte of the range. The other, implicitly derived from the runtime value and the size information in the pointer type, refers to the location after the last byte of the range. When we think of memory addresses as the article's indexes, and pointers as the article's ranges, everything falls into place.
(Incidentally, please be careful calling out people for not understanding computers. C isn't actually the lowest level of computing, and pointers aren't as primitive as your post implies. When you call someone out, you need to be 100% clear and 100% right.)
Re: Indices Point Between Elements
#24I've found this a helpful way of explaining ranges in Python to students, it also makes Python's negative indices understandable for the same reason. But it is contextual. When it comes to languages like C, where arrays are more directly mapped to pointers and memory layout, I've found it better to talk about pointers, and allow people to derive the behavior that way. Either way, I'd be careful of trying to claim tha…
I get into this a bit later on, but I think the exact same model applies to pointers: You're much better off in most cases thinking of pointers as pointing at the zero-width points between elements, than at elements themselves.
Re: Indices Point Between Elements
#25When you talking about where zero-width regexes match, this mental model certainly helps, and I find it consistent otherwise too.
zero-width matches (and empty lines) were a huge source of stupid edge-case bugs in livegrep[1], and being rigorous about maintaining this mental model definitely helped a lot.
[1] livegrep.com
Re: Indices Point Between Elements
#26The visuals are definitely valuable in explaining this. It used to be popular, and still is in some circles, to debate whether programming languages ought start array indexing at 0 or 1. When talking about this with other programmers, I've discovered that a lot of the issues/confusion could be avoided by consistent use of terminology: Offsets/offsetting always being zero-based and indexes/indexing always being one-ba…
_It used to be popular, and still is in some circles, to debate whether programming languages ought start array indexing at 0 or 1_ this is an exemplary case of citation needed if I ever saw one. maybe it's a valid debate for programming languages that doesn't allow people to do pointer arithmetic, which already restrict the field a lot, but even then that's sound as part of the 4GL bullshit that never really took of…
> sound as part of the 4GL bullshit
Actually it's primarily early languages plus Lua.
[0] https://en.m.wikipedia.org/wiki/Comparison_of_programming_la...
Re: Indices Point Between Elements
#27The visuals are definitely valuable in explaining this. It used to be popular, and still is in some circles, to debate whether programming languages ought start array indexing at 0 or 1. When talking about this with other programmers, I've discovered that a lot of the issues/confusion could be avoided by consistent use of terminology: Offsets/offsetting always being zero-based and indexes/indexing always being one-ba…
I prefer that model for floor numbering, personally. It means if you're on floor N that you're N stories above the ground.
Not that it matters, but I feel the opposite. Barring the presence of subterranean levels, if you're on the ground floor, you are standing on the first literal "floor" of the structure.
Re: Indices Point Between Elements
#28[deleted]
Re: Indices Point Between Elements
#29Ugh. Please no. This only adds to the confusion, as now there are 2 ways in which indices can be interpreted.
Specifically, this:
>"Indexing between elements, instead of indexing elements, helps avoid a large class of off-by-one errors."
It only replaces them with indexing-method errors. Instead of remembering if my ranges are open or closed, I have to remember if they are using between-element indices or on-element indices. It's still going to cause the same kinds of problems.
Re: Indices Point Between Elements
#30People have taken different approaches to this in bioinformatics for numbering intervals of dna bases in chromosomes. I think this approach is catching on, though. In that realm, it's important to speak unambiguously about insertions and deletions, and the "interbase" mental model makes it a lot clearer. edit: Probably the most popular genome browser, based at UC Santa Cruz, uses this zero-based, half-open numbering…
One interesting side-effect of using 1-based closed indexing (i.e. numbering the positions, not between the positions) is that a zero-width range (which is something that actually comes up in genomics) starts at position N and ends at N-1.