0-indexed vs 1-indexed

But why? Things don't just start at 1 things start at 0.

I think I touched on this briefly earlier in the thread, but it's more intuitive to start everything from 1. You don't write your shopping list starting with item 0 (unless you've been a programmer way too long ).

I think the reason computers traditionally index from 0 is because the address of the nth element in an array starting at address a is a + (n * size), which just so happens to mean the first element is the one with n = 0. If you did it 1-based, it'd be a + ((n - 1) * size), which introduces another subtraction operation, which in the 70s or 80s (when all this stuff was being designed), meant your computer could run significantly slower.

That's not really relevant today, especially in Construct which has such large overheads for the event engine, it makes no difference performance wise whether we choose 0-based or 1-based. 1-based is more intuitive, as mentioned above, so we go for that.

I'm posting this question here, because my random-event changed, naturally, after the lastest build.

Question: random(4) means: Choose a number from: 1, 2, 3, 4?

(In previous build it meant: choose a number from: 0, 1, 2, 3, 4)

If yes, then it seems v0.98.8(rich build) doesn't work like this. Or I am doing something wrong

, or perhaps a bug...

No, it doesn't include the 4. It is really a number from the array of {0,1,2,3}.

So a random(4) will return a whole number between 0 and 4, including the 0 and not including 4. Confusing, I know, but you get used to it.

I think I've found a bug in the indexing of arrays, as well as a bug with reading a value using "get value at x,y,x).

See this post for details:

Basically, the first problem I found was that using "get value at x,y,z)" didn't seem to flag a match when it should have.

The second problem, and the one more related to this thread, is that it appears that arrays (in the newest 98.8 ) are using both 0-indexed and 1-indexed.

Try it.

Set a value in a 3d array like Array(5,5,5), and then search for that value.

You'll find it in Array(4,4,4).

My tutorial will have to be put on hold until this is sorted, because the goalposts seem to keep moving.

I dont understand all the hate for 0 based, in fact I'd much prefer it if everything was 0 based.

I mean the "shopping list" argument doesn't really convince me.

By a similarly hand-wavy argument, you don't draw a line starting from the point (1,1) you draw it through the origin (I know this makes no sense at all).

Anyone who's used an array before will probably be used to it being 0 based. Anyone who hasn't will probably end up looking in help and see that it's 0 based if they assume 1 based at the start.

I know this is a consistency thing, so I understand that, but 1 based arrays seem a bit odd.

Also, is find and replace working? (I don't really feel like testing, last time I did it completely broke my game and I couldn't undo), if it is you could just do FIND loopindex REPLACE WITH loopindex-1 and hit replace all, if it's not then PLEASE FIX

Also, is find and replace working? (I don't really feel like testing, last time I did it completely broke my game and I couldn't undo), if it is you could just do FIND loopindex REPLACE WITH loopindex-1 and hit replace all, if it's not then PLEASE FIX

What's wrong with testing it out? It's not like you have to save your messed up .cap, if it does mess up. Hell, you don't even have to use an original... you could make a copy before you even start.

Also, I think 1-index makes more sense to the layman, which is what most Construct users will be. 0-indexed makes sense from a programming background, yes, but most people use game making tools because they're not programmers. And yes, there has been a lot of confusion over 0-index in the past... many people have asked for help wondering why their stuff didn't work, expecting things like random(3) to give 1, 2, or 3. So it's not like it's unwarranted. The grocery list analogy isn't the only reason it's being changed.

Further tests on the current state of array indexing shows something odd.

Even though we now know that the current build has a bug that means "writing" to an array uses 1-indexing, and "reading" from an array uses 0-indexing, we can't use that knowledge in the meantime to fudge a workaround because the first index seems to be unreadable.

For instance;

+ Array:Set Size to 8x8x4

+ Array:Set Index (5,5,1) to 91

+ Array:Set Index (5,5,2) to 92

+ Array:Set Index (5,5,3) to 93

+ Array:Set Index (5,5,4) to 94

creates the array and sets those 4 values in the separate Z indexes.

Now looking for them in (5,5,n) won't work in the current build, as we know, but we should find them in (4,4,n).

But if we look in the those 4,4,Z indexes, we find the values 0,92,93,94

The first index is never retrievable.

This may be fixed as a consequence of fixing the original bug, but I would like to ask the Devs to check the array functions carefully before the next release, as this may be a new bug.

Cheers,

Sponge.

I don't think it's that important, as long as it doesn't change. Ever.

No, it doesn't include the 4. It is really a number from the array of {0,1,2,3}.

So a random(4) will return a whole number between 0 and 4, including the 0 and not including 4. Confusing, I know, but you get used to it.

But it seems to me that "including 0" is not 1-indexed (start counting at 1).

What you describe, Mipey, is how most (all?) programming languages handle it, if I'm not mistaken.

Or is 1-indexed not implemented yet, in the latest stable build?

Sorry to bump this, but this is just plain retarded. 1 based does not equal more intuitive, it does for some people, but a few people does not mean everybody. The logical choice is to let the user choose to use a 0 based or 1 based array, as certain situations arise where you WILL need a 0 based array, otherwise you will need use complex unnecessary math in order to get the desired result.