"Nobody" <nob...@nowhere.com> wrote in message
news:pan.2010.08.07.15.23.59.515...@nowhere.com...
> On Sat, 07 Aug 2010 13:48:32 +0200, News123 wrote:
>
>>> "Common sense" is wrong. There are many compelling advantages to
>>> numbering from zero instead of one:
>>>
>>> http://lambda-the-ultimate.org/node/1950
>>
>> It makes sense in assembly language and even in many byte code languages.
>> It makes sense if you look at the internal representation of unsigned
>> numbers (which might become an index)
>
> It also makes sense mathematically. E.g. for an MxN array stored as a
> 1-dimensional array, the element a[j][i] is at index
>
> j * N + i
>
> with zero-based indices but:
>
> (j-1) * N + (i-1) + 1
> = j * N + i - N
>
> with one-based indices.
In other words, an extra offset to be added, in an expression already using
a multiply and add, and which likely also needs an extra multiply and add to
get the byte address of the element.
(And often, the a[j][i] expression will be in a loop, which can be compiled
to a pointer that just steps from one element to the next using a single
add.)
The indices i and j might anyway be user data which happens to be 1-based.
And if the context is Python, I doubt whether the choice of 0-based over a
1-based makes that much difference in execution speed.
(I've implemented languages that allow both 0 and 1-based indexing (and
N-based for that matter). Both are useful. But my interpreted languages tend
to use 1-based default indexing as it seems more natural and 'obvious')
>
> IOW, if a language uses one-based indices, it will inevitably end up
> converting to and from zero-based indices under the hood,
Sometimes. At the very low level (static, fixed array), the cost is absorbed
into the address calculation. At a higher level, the cost is less
significant, or there might be tricks to avoid the extra addition.
> and may end up
> forcing the user to do likewise if they need to do their own array
> manipulation.
Lots of things require this sort of calculation, eg. how many pages are
needed to print 267 lines of text at 60 lines per page? These counts are
1-based so it's (L-1)/P+1 (integer divide), or 5 pages.
If we switch to 0-based counting, it's just L/P ('266' lines require '4'
pages), but who's going to explain that to the user?
--
Bartc
--
http://mail.python.org/mailman/listinfo/python-list
