Okay. This should be a simple problem. I found the Series component and connected two sliders to it. Everything was fine until, following instructions in the tutorial, I typed in the expression (C*2)+1 for the count input and got the error that it did not know the variable C. ??series-problem.gh (4.3 KB)
The variable you use in your expression has to be the same as the one in the inputs. If the inputs are ‘x’ and ‘y’, then you must use those in the expression. Or, change the input ‘x’ to ‘c’ and it will work.
For some time now all input variables use “x” rather than the input name for expressions directly on the component inputs. So should be (x*2)+1. Consider “x” as representing any input variable.
NOW you tell me. Yeah, I was some kind of confused because I used C because in the help info for the Series component it said that the Count input was called C.
This is becoming very frustrating. I can’t cook if I’m looking for a spatula and you’ve decided to call it a whisk.
I can’t cook if I’m looking for a spatula and you’ve decided to call it a whisk.
I think your frustration is valid but also you will realize it is better that things become more universal. Imagine you need that equation for multiple components you would have to keep changing the letter, now you do not. More like having one tool which can be a spatula or a whisk
If I am looking at a component and it says that its input is C, then I should be able to write (C*2)+1 and have it be valid. Otherwise, the input should be called x. Code writing needs consistency and logic, and the rules need to be explicit. I’ve written lots of code over the years in assembly, C, and C++. I’ve written code for Windows which can be very infuriating. I find that trying to learn Grasshoper is like writing code for WordPress, which I have done, where things are not as they seem and it takes a long apprenticeship to learn the tricks.
If I am looking at a component and it says that its input is C, then I should be able to write (C*2)+1 and have it be valid. Otherwise, the input should be called x.
Not necessarily. In code that makes sense because you are dealing with many variables. In the case of writing an expression into a single input it is always and will always be alone, so a universal variable name makes sense like algebra. Another reason is that Gh inputs are re-nameable, without the “x” then it may be hard to share definitions between friends if they prefer not to have what you renamed the input to. Also what would you do for the guys who are using full names? Will they just have to type (Count*2)+1 and then the component will fail if they switch back to single letter input names?
Or if the developer decides to change the name of that input on a future release - then all the old definitions with expressions will fail. The universal “x” solves many issues.
I do think though that information could be better documented. Maybe some message like “variable is x” when you hover over the expression option.
The change from parameter name to
x was made for the following four reasons:
- Using the same variable name all the time makes it easier to copy/paste expressions between parameters.
- By disassociating the expression variable from the nickname, the nickname can be changed without having to modify the expression. This was especially annoying with the ‘Full Names’ option, which replaced nicknames with full names.
- By always using the same name, you do not have to look at the component when you type your expression, it requires less information to get started.
- Most importantly, there are pretty strict rules about legal variable names (alphanumerics and underscores only, can’t start with a number). Nicknames have no such restrictions. Under the old scheme that meant you could not name an input “Value B” and have an expression for it at the same time.
The new scheme is every bit as consistent, logical and explicit as the old (in fact more so I’d say), but of course if you’re used to the old way, then it will be confusing.
While you make some compelling arguments for your way, I don’t agree. The system you describe is what my old boss would probably have called “sloppy”.
I’m completely new to Grasshopper. I’m trying to learn. I’m frustrated by the lack of documentation that I can find. If not for this forum and the help I’ve gotten from it, I would have pitched the program out the window. So if I sound like I’m beating you over the head, it’s not personal, just my frustration coming out.
In most cases, ‘Expression’ is a right-click option on inputs or outputs that always refers to “x” as the value passing through it. These are the only two components where expression variable names other than “x” are expected, both in ‘Maths | Script’: Evaluate and Expression
One says sloppy, the other says convenient. These practices do kind of exist in code in a way. Look at c# where commonly people use “i”, “j”, “k” in for loops as kind of throwaway counter variables.
The real issue is not even a lack of documentation, it is that for a very long time up until now Grasshopper was a Beta so any documentation quickly becomes obsolete. That is why they say you should never rely on Beta software - it is usually subject to breaking changes, however grasshopper is a unique rare case where the Beta gets super popular, almost faster than it can solidify. There have been cases where people wrote books for Grasshopper and a month later the book is almost completely irrelevant. I think we will start to see strong documentation coming for Grasshopper because it is now a full part of Rhino.
's all right, part of the deal of writing software. In my experience two types of people have trouble with Grasshopper, those who can’t bring themselves to think algorithmically* and those who are already fluent in programming and who expect certain patterns that aren’t there in GH.
Lack of (official) documentation is indeed a severe shortcoming. There’s great user generated content out there, but we will be striving to provide much better out of the box documentation for Grasshopper 2.0
* This is not supposed to be an insult, people think in many different ways.
Grasshopper hasn’t changed much over the past couple of years. There’s been plenty of bug-fixes and a few new components, but nothing that would invalidate most information/instruction.
McNeel & Associates will almost certainly not be working on documenting GH1. Apart from serious bug fixes and maybe some new features which could plausibly be argued to fall under ‘proof-of-concept-experiments’, all the effort should go into GH2 from now on.
The example I refer to was Arturo Tedeschi’s book which came out right before shortest, longest, and cross reference became separate components. Which made him have to rewrite a new version a month later :D. What I meant was GH2 yea.
Thanks everyone for the inputs. I have a little bit better perspective on GH now than I did. I expected a more finished product. I have only used Rhino5 for about a year and love it for what I can do with it. I’ve had some difficulties with it that were only solved through the forum. So now I am trying to decide whether to upgrade to Rhino6, mostly because of the inclusion of Grasshopper. I very much like the idea of parametric modeling for some of the things I do. And I admit to a stricter sense about programming rules than many coders out there. For me, the name of a variable can have an important effect on my understanding of a program when I look at it 6 months later. I can swallow different ideas. What gets my goat is not knowing and having no way to find out so that I spin my wheels until I get aggravated enough to post a question. The very best thing that McNeel could do would be to put together a good, up to date textual explanation of what Grasshopper is and does along with a basic tutorial on how to find components and how variables are treated. The short videos are okay but don’t cover some of the basic rules and philosophy that I need to know.