algorithmic modeling for Rhino
I would like to know why the index of the first item in a list is "0" and not "1".
Apart from making tree structures even more difficult to work with and generating bugs when one has forgotten to add a "-1" component each time you need the "N th" component in a list, what is it good for ?
Is it just a programmer's frivolity, or does it actually have a practical reason ?
I can see that it allows to use a boolean input to select either the first (N°0) item, or the second (N°1), but other than that... ?
Cheers,
Tags:
Other than Anders link, here's another reason:
... and then the Lord said: "I will blot out 1 from the face of the Lists/ILists, from Arrays/DataTrees to HashTables/Queues and from IEnumerables to IQueryables; for I am sorry that I have made it (the non zero indexing thingy, that is)"...
Note: He haven't mentioned Tuples, though.
Hmm...
Just as I though : obscure programmer habits from the old days of the punch-cards.
:)
Remarkably many features of programming languages are due to historic reasons rather than good reasons.
However there are definitely cases where beginning at zero makes the mathematics needed inside iterations a lot easier.
However there are definitely cases where beginning at zero makes the mathematics needed inside iterations a lot easier.
Oh, well I guess I keep bumping into all the other cases where it's a pain in the neck :)
Waclaw Sierpinski, the great Polish mathematician was worried that he'd lost one piece of his luggage. "No, dear!" said his wife. "All six pieces are here." "That can't be true," said Sierpinski, "I've counted them several times: zero, one, two, three, four, five."
Occidental culture has accustomed us to that zero means nothing, but that is not so. Zero represents a value in itself, is not always absence (a newborn baby carries zero days in the world).
Someone correct me if I'm wrong, but I think the indexes in programming are not an object in itself, are a number indicating the displacement of a collection of elements, therefore, the zero index is the first element, because it still has not emerged a displacement, is the origin of the collection.
If the indexing is treated as an cardinal number, then starting with 1 makes the most sense. The 'first' item in a collection should be at index 1, the 'second' item at index 2. If however the index is treated as an offset or ordinal number, then 0 is actually quite rational. We find the first item at the start of the collection plus zero. The second item can be found at the start of the collection plus one.
In the end certain things are easier and others are harder, so it is difficult to really say which approach is better. Certainly beginners often run into this problem, but almost all the mathematics I use inside loops would become more complicated if indices started with 1.
I do feel very strongly that the system is consistent though, the long time VisualBasic approach of being able to specify whether you want zero-based or one-based arrays is evil.
Yeap, but what do you mean with evil? why?
Olivier, in the end one is accustomed to starting from zero, it ceases to be a nuisance, at least for me. The Grasshopper magic is that without realizing it forces you to think like a programmer, and then the transition to code is more a formal aspect, rather than a conceptual aspect. I also thought three years ago that programming was out of my reach, and now I'm addicted! :3
Grasshopper "looks" like a programming language for non-programmers, with it's explicit and colorful layout of parameters and operators.
This might not be the original intent, but I noticed at least in the place where I work that everybody wants to have a pop at making definitions ; even people who it would never try in their wildest dreams to write down a line of code.
In effect, Grasshopper draws lots of people to the algorithmic world by it's sexyness and apparent simplicity.
That's why this type of counter-intuitive notions (Fifth object is N°4 in the list) appears so much out of place.
There are also many operations which are MORE difficult to perform Grasshopper than in the usual text line based languages.
The "If... THEN... ELSE..." statement for instance : it takes some head scratching in Grasshopper to formulate this kind of logic.
For example, if you want to display a message depending on the relative size of two values, you would simply type :
IF a<b THEN PRINT "a is smaller then b" ELSE
IF a=n THEN PRINT "a is equal to b" ELSE
PRINT "a is larger than b"
In GH, (attached), this would require finding a clever way to convert booleans to indexes.
Not quite straight forward...
Cheers,
Hello Olivier,
The [expression] component can handle IF/THEN statements quite well:
In regards with the index numbering, having continuous numbering helps with any operation that requires wraping the list:
Of course now we have to use that x-1 expression quite often but, in the opposite case, we would have to cull 0's as often...
Welcome to
Grasshopper
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
© 2024 Created by Scott Davidson. Powered by