Python "why" questions

[Bartc]

"Nobody" <nobody at nowhere.com> wrote in message 
news:pan.2010.08.07.15.23.59.515000 at 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