3 ms·
I think the main problem with 1-indexing is that it makes some formulas that depend on the length of an array more complicated. Not a huge problem, but it's kin
by philipov 6y ago
I think the main problem with 1-indexing is that it makes some formulas that depend on the length of an array more complicated. Not a huge problem, but it's kind of annoying.
- OkayPhysicist 6y agoIt replaces the standard [0,len()) with an [1,len()], though, which correspondingly makes other tasks easier. Plus it matches normal mathematical vector indexing. In the end, in a language where you aren't doing pointer arithmetic, the sides are pretty even. We just tend to side with tradition, because it's easier to.
- sergeykish 6y agoI found it uncomfortable when drawing on screen: y = margin + (i - 1) * lineheight
- wruza 6y agoy = 1 + ... if y is 1-based too (which feels even more uncomfortable). But it would be nice to have such functions out if the box: canvas.linear_index(x, y, stride) vbox.y1_for(margin, spacing, height, i) vbox.y2_for(margin, spacing, height, i) And then you have "integer at the center of a pixel" vs "integer at the top-left of a pixel" differences, which should be taken into account by these functions too. Stroke 1: y+0.5, y+height-1. Stroke 2: y+1, y+height-2. Fill: y, y+height. Pixel geometry is hard on its own.
- wruza 6y agoOff by ones happen with 0-based too (to me at least, at "write the new codez" stage). What languages are really missing is some stdlib for hiding these calculations under easily understandable names like nthfromend, nfromto, revidx, last, etc. Too much of n-1, n-i-1, -i-1, b-a+1, <, <= to maintain in correct ranges either way. 0/1-based are simply two degenerate around-off-by-one cases of working at general n-based offset, since both 0 and 1 are the most common results of off-by-one.