The dreaded Element Zero rears its..

[Anteaus]

Just an opinion (so flame it if you wish) but I'd vote for zero-based indexing of arrays and strings NOT becoming a feature of AutoIt.

I raise this as while the de-facto AutoIt standard is for one-based indexing, the dreaded Element Zero seems to have been creeping-in to some inbuilt functions.

Zero-based indexing is the more common arrangement in other languages, hence there is probably a pressure to 'conform to the norm' even if that norm is a less-effective arrangement.

The origins of zero-based indexing lie in the dark and distant days of early computers, when it was essential to use every single byte of extremely costly and limited memory to best advantage. In the modern environment of vast amounts of cheap memory it has no significance.

Anyone who cares to to do a comparison of routines between, say AutoIt and php will have to agree that one-based arithmetic yields logical and consistent results with the minimum of 'adjustments' needed. Plus, one-based code rarely needs exhaustive debugging, the results are usually correct first time.

Zero-based arithmetic gives rise to the need for incessant 'adjustments' to returned values by +1 or -1 to achieve correct results. This arises owing to the number of elements in the string or array being -paradoxically- unequal to the upper bound. IME, zero-based manipulations seldom work first time, often needing time-consuming debugging of these 'adjustments.'

So, zero-based indexing offers a very small advantage, but at a huge price of unclear and hard-to-read code, filled with confusing offset-adjustments.

I vote for sticking to the original design-principles of AutoIt, namely one-based indexing of strings, and where arrays are returned by functions, the zeroth element being used to indicate the quantity of elements returned, with the first data element being element ONE.

[weaponx]

Have you lost your mind? You must be referring to the changes to StringSplit() which are *optional*. What language uses one-indexed arrays?

[Richard Robertson]

Even languages like VB have dropped support of declaring your array NOT at index 0.

AutoIt has been using 0 based indexing from the beginning.

[Valik]

I vote for sticking to the original design-principles of AutoIt, namely one-based indexing of strings, and where arrays are returned by functions, the zeroth element being used to indicate the quantity of elements returned, with the first data element being element ONE.

It was not a design principal, it was a "we don't have UBound() so we need to return the size somewhere". We now have UBound(), thus not starting at index 0 is redundant and pointless.

If you don't like 0-based arrays, fine. But keep in mind that there are others who don't have a problem with it or maybe even prefer it to 1-based arrays. So in the future you might wish to spare the hypocritical my way is better than yours diatribes. Just a thought.

[weaponx]

Does Ubound actually perform something labor intensive like searching an array for a sentinel or does it just return a number tracked internally by AutoIt?

[jvanegmond]

I'd get so confused to the point where it would almost impossible to write code if this language started using one-based indexing.

[weaponx]

These benchmarks are strange. It seems Ubound is *faster* on larger arrays.

Dim $a1[10]
Dim $a2[100]
Dim $a3[1000]
Dim $a4[10000]

$t1 = TimerInit()
Ubound($a1)
ConsoleWrite("a1: " & TimerDiff($t1) & @CRLF)

$t2 = TimerInit()
Ubound($a2)
ConsoleWrite("a2: " & TimerDiff($t2) & @CRLF)

$t3 = TimerInit()
Ubound($a3)
ConsoleWrite("a3: " & TimerDiff($t3) & @CRLF)

$t4 = TimerInit()
Ubound($a4)
ConsoleWrite("a4: " & TimerDiff($t4) & @CRLF)

a1: 0.0125599929825441
a2: 0.00500369669553013
a3: 0.00466911442212504
a4: 0.00395859701006253

[Richard Robertson]

Try running the tests in the opposite order. Perhaps it is just that the program was still "starting up".

[jvanegmond]

AutoIt internally keeps track of the length of each subscript. The Ubound function internally uses the ArrayGetBound method, which just returns the length. Correct me if wrong.

[weaponx]

Try running the tests in the opposite order. Perhaps it is just that the program was still "starting up".

Very strange. It seems like the more you call Ubound the faster it gets. I think its safe to assume that AutoIt must track the array sizes internally which makes sense.

The whole point of this was just to see if there was a significant decrease in performance by using Ubound() vs. storing the element count in [0]. The hit is barely even noticeable.

[Anteaus]

The whole point of this was just to see if there was a significant decrease in performance by using Ubound() vs. storing the element count in [0]. The hit is barely even noticeable.

This is interesting but only peripherally relevant to my point, which is that zero-based data leads to messy and bug-prone code, code filled wlth +1,-1,+1,-1.. 'adjustments' to indices. One-based data leads to elegant string or array-handling code, code which makes sense to a human, and which in most cases needs no 'adjustment' for values to make sense.

Actually, it gets worse than that. Let's take an example. In php, the stripos() function -roughly equivalent to StringInStr()- returns zero if the substring is not found, as you might expect .. but also returns zero if the substring is found in the first location, the indexing being zero-based. To determine which you have requires a special test with the "===" operator.

I daresay this could have been avoided by using -1 to indicate 'not found' instead of this daft arrangement, but I just mention this to underline the sheer levels of confusion that zero-based indexing can sometimes lead-to.

After years of putting-up with the hassle that zero-based logic creates, I had come to realise that the AutoIt way of doing things was actually a better way, and was 'fraid that we were about to depart from that way in the interests of conformity with the ancient and decrepit C paradigm.

[Valik]

This is interesting but only peripherally relevant to my point, which is that zero-based data leads to messy and bug-prone code, code filled wlth +1,-1,+1,-1.. 'adjustments' to indices. One-based data leads to elegant string or array-handling code, code which makes sense to a human, and which in most cases needs no 'adjustment' for values to make sense.

Elegant? Elegance only comes about when iterators hide the index. There is no elegant solution involving an index.

Actually, it gets worse than that. Let's take an example. In php, the stripos() function -roughly equivalent to StringInStr()- returns zero if the substring is not found, as you might expect .. but also returns zero if the substring is found in the first location, the indexing being zero-based. To determine which you have requires a special test with the "===" operator.

I daresay this could have been avoided by using -1 to indicate 'not found' instead of this daft arrangement, but I just mention this to underline the sheer levels of confusion that zero-based indexing can sometimes lead-to.

Don't blame indexing for the problem, blame the developers for not coming up with a better solution. Indexing is not the problem in your example, poor design is.

After years of putting-up with the hassle that zero-based logic creates, I had come to realise that the AutoIt way of doing things was actually a better way, and was 'fraid that we were about to depart from that way in the interests of conformity with the ancient and decrepit C paradigm.

AutoIt arrays are 0-based. AutoIt strings seem to be 1 based. So you are suggesting inconsistency is better? I never thought about it until now but I consider it a language flaw that strings are treated one way and arrays are treated another.

This whole argument is stupid. I can make the exact same arguments for why one-based is just as bad as zero-based. I have to adjust for cases using one-based just as much as for zero-based. The reason I'm not bitching about it is because I don't care. I do what's necessary to get the job done. I don't sit around and bitch "oh, these arrays are one-based causing me to do more work" because I don't evne pay attention and I don't feel like I'm doing any more work than I would if they were zero-based.

[Anteaus]

Elegant? Elegance only comes about when iterators hide the index.

That is true, and the capability to say $widgets[green] or $widgets.green instead of $widgets[7] makes things more readable. (Actually you can simulate that behaviour by declaring $green=7) But then, this is getting dangerously close to OOP and another flame-war.

Arrays: Here AutoIt has always allowed a zeroth element, but has traditionally its functions have returned data starting with #1. Recently we've seen some changes, for example regexes return a zeroth element. My view on this is that zero-based arrays create a lot of extra 'adjusting' but can at least be lived-with.

Strings: It is when making reference to substrings that zero-based indices really suck, every startpoint and endpoint having to be adjusted down by one, and every result adjusted up by one in order to make human-sense. Also, consider the question, "Where in the string "manpower" do I find the substring "man" ? AutoIt traditionally would reply "One" which is also equivalent to TRUE, in other words, "Yes I did find it."

Zero-based languages would reply "Zero" which is also equivalent to FALSE, thus making the totally loopy statement, "I found it straightaway, but I did NOT find it!" Thus a paradox is created, and the returned information doesn't, on the face of it, make sense. This kind of situation is best avoided.

-Catch my drift?

[BrettF]

I fail to see why you are making connections with the indexes of arrays and Boolean values...

Heres some advice now. Deal with it. As Valik has said, the reason for the size being returned in zeroth index was because of no UBound feature. Now they have it, wasting that zeroth index is pointless...

And this is probably the only time I will quote Valik directly... This whole argument is stupid.

Cheers,

Brett.

[Wus]

My two (superfluous) cents:

Zero-based indexing is better because it more accurately represents what is happening in memory. The 0-index is simply saying that the offset to the memory location is zero. Whatever your talk of cheap memory, no self-respecting computer scientist would EVER create a language that wasted the first index of an array. The compromise between these would be to internally just subtract one from the users index, allowing the user interface to be 1-based and the internal mechanism to be 0-based, but this is only an un-needed complication. Remember the KISS principle?

Also, on a side note... 0-based indexing is pretty universal--I'd say that mathematicians use a 0-based index much more than a 1-based index for products and sums.

Edited April 29, 2009 by Wus

[Valik]

That is true, and the capability to say $widgets[green] or $widgets.green instead of $widgets[7] makes things more readable. (Actually you can simulate that behaviour by declaring $green=7) But then, this is getting dangerously close to OOP and another flame-war.

I fail to see what member accessor syntax has to do with iterators. For...Each gives (read-only) iterator like behavior for arrays, by the way.

Arrays: Here AutoIt has always allowed a zeroth element, but has traditionally its functions have returned data starting with #1. Recently we've seen some changes, for example regexes return a zeroth element. My view on this is that zero-based arrays create a lot of extra 'adjusting' but can at least be lived-with.

My view is that it does not. I find I have to adjust those one-based arrays a lot as well. You just don't like zero-based and so you're (possibly unintentionally) using hyperbole to get your point across.

Strings: It is when making reference to substrings that zero-based indices really suck, every startpoint and endpoint having to be adjusted down by one, and every result adjusted up by one in order to make human-sense. Also, consider the question, "Where in the string "manpower" do I find the substring "man" ? AutoIt traditionally would reply "One" which is also equivalent to TRUE, in other words, "Yes I did find it."

It makes sense to me the way things are with zero-based. Maybe you're just broken?

Zero-based languages would reply "Zero" which is also equivalent to FALSE, thus making the totally loopy statement, "I found it straightaway, but I did NOT find it!" Thus a paradox is created, and the returned information doesn't, on the face of it, make sense. This kind of situation is best avoided.

-Catch my drift?

I've never run into this problem.

[Richard Robertson]

My two (superfluous) cents:

Zero-based indexing is better because it more accurately represents what is happening in memory. The 0-index is simply saying that the offset to the memory location is zero. Whatever your talk of cheap memory, no self-respecting computer scientist would EVER create a language that wasted the first index of an array. The compromise between these would be to internally just subtract one from the users index, allowing the user interface to be 1-based and the internal mechanism to be 0-based, but this is only an un-needed complication. Remember the KISS principle?

Also, on a side note... 0-based indexing is pretty universal--I'd say that mathematicians use a 0-based index much more than a 1-based index for products and sums.

The compiler would be given the job of reassigning all the indices. The compiler has "all the time in the world" to quote Tanenbaum. The execution wouldn't have that problem of adjusting indices.

[weaponx]

Some good examples and arguments here:

http://en.wikipedia.org/wiki/Array

http://en.wikipedia.org/wiki/Comparison_of...-reference_list

[Anteaus]

OK, I tried to raise this as a sensible discussion topic, and all it generated was a series of ad-hominem attacks.

Why, I ask? Is this any different from debating whether to use a beige or black case? Or between Athlon and Pentium? On the face of it, no.

Actually, yes there is. Zero-based arithmetic is a cornerstone of college and uni computer-science courses, and I reckon the issue here is nothing to do with advantages or disadvantages, but of going-against the time-honoured and revered writings of those with strings of letters after their name. Of challenging 'status quo' in a way which might be seen as <gasp> heresy.

The issue here, I fear, is one of entrenched views, and a cultlike reverence for textbooks.

Edited April 29, 2009 by Anteaus

[Richard Robertson]

The zero has nothing to do with tradition. It has to do with speed.