Newbie question: I’m trying to set a variable n in graph graphIncreasing.
number(n): 200
parses, but doesn’t seem to have an effect.
graphIncreasing.number(n):200
doesn’t parse => expected identifier
in the code, n both times is surrounded by a tick mark, but I don’t know how to put that into this question,
thanks
number(`n`): 200 should work so long as it’s in the graph’s CL. You can’t define it from a different component as it appears you’re trying in the latter. (Surround your code with triple backticks to format the code in this forum. Triple backticks on a line before and after for multiple lines of code.)
You can define numbers using variables, calculations, or conditionals as well:
a= input2.numericValue
number(`n_1`): numericValue(`100^{2} - 36^{2}`)
number(`n_2`): table3.cellNumericValue(1,3)
number(`n_3`): when a<4 a otherwise 0
A link to your activity and/or a description of what you’re not seeing that you expected to see would be helpful.
Thanks! My main problems turned out to be spelling. I’m adding CL to this activity:
I’m on slide 2 and will proceed to later slides. Issues on slide 2 CL in graphIncreasing:
pointLabel(`R_ule`): `Circular Rule: k -> mk mod 200`
I’d like to modify the above line to:
– replace m with the value of m
– regular font, not italics
– replace “->” with Latex \longRightArrow
I’ve also used some cool CL on the Group Formulas slide (9) to allow students to write a function. The calculator doesn’t allow me to say N(m) = 2m —fine— but it would be great if the student could use m as an independent variable, and have CL replace all "m"s with "x"s.
Thanks again.
First, if the subscript has more than one character (unless possibly it’s a number), then it needs to have curly braces. Second, I’d use quotes for the whole of the label, but you can use backticks within for the k–> mk mod 200. Use ${ } for variable content in. Not sure if long arrow will work for latex, but you can always copy-paste a long arrow character like below
m= whatever your m is defined by
pointLabel(`R_{ule}`): "Circular Rule: `k⟶${m}k mod 200`"
For simpleFunction you need to define the independent variable, if it’s not x: simpleFunction(FormulaInput.latex, "n").
Curley braces seem to be required and work for:
number(`h_{Rule}`): 1.7
They provoke an error if used here, and it works without them:
pointLabel(`R_ule`):"Circular Rule: `k⟶${m}k mod 200`"
Actually, the previous line with a copy-pasted string from your reply has this error:
Unable to find component or variable m
I found another problem. This setting:
number(`n`): 10
blows away the lower and upper bounds for n as well as the step size. n was established as:
1<=n<=200 [step=1]
but that goes away. Also, the slider for n doesn’t show a moveable point until I bump it with the inc/dec triangle buttons.
Thanks
Oops. That’s right. I was thinking for numbers or numberLists.
With the above code, you need to define m in the CL, otherwise use ${this.number(`m`)}, or whatever the source of m.
As to defining the number, it overwrites as though starting from scratch, so if you want to maintain the bounds, define “n_0” in the CL and have n in the graph defined as n=n_0, that way you maintain your bounds.
Independent variable:
GREAT improvement; THANKS!
using this. => great
Avoiding starting from scratch => I don’t get it yet, I’m afraid.
In the graph, if I define n=n_0, it’s n_0 that gets bounds, and n doesn’t. Then I have the same situation when defining n_0 in the CL. What am I missing?
When you write number(`n`)=10 in your cl, you’re telling the graph that you want the graph’s variable n to have the value 10 — always! That is why your moveable point becomes fixed… it’s the same as the difference between a and b in this graph: https://www.desmos.com/calculator/kpt9rtjart
You can overwrite a CL sink’s update with an action update inside the graph, which is what you were seeing with the moveable point appearing after hitting your inc/dec actions. Hit my action in line 6 for the link above to see what happens with the definition for b.
If you are thinking of CL as providing a “starting value” for the parameter n, then your moveable should probably be defined as something like (n+n_{studentOffset},0), where n_{studentOffset} is prepared in the graph with bounds that prevent n+n_{studentOffset} from reaching below 0 or above 200. Then, your inc/dec actions would modify n_{studentOffset}, leaving n free to be modified through CL.
That feels like overkill, though — if you save your graph with n=10, that becomes the default position for the slider when students start the activity! No CL needed.
(As an aside, I’m seeing some performance lag with all those linear equations graphing against each other and looking for points of interest. I recommend building those segments as polygon expressions! Here’s an example of what that might look like: Graphing Calculator)
Thanks for writing code. I see that you used polygons rather than bounded lines. I love how you assigned colors! This will take some time to absorb.
My graph services different slides by setting certain values. I had been customizing the graph in each slide before I started learning CL last week. By setting values in CL, I can more easily use the same graph. Can I trigger a graph action from CL? I obviously need to rewrite my code, so I don’t mind restructuring. Also, can I turn on/off displaying a folder in the graph from CL?
I see, that makes sense! So then yes, I’ll recommend the “offset” approach.
CL can’t trigger a graph action directly, though there would be some clever things you could do with a ticker. I don’t suggest going down that route.
CL also doesn’t give you any control over folder visibility, but you can create toggles for yourself in the graph. Something like {1=s_{howModulusControl}} attached to your various expressions will cause them to be undefined (and therefore not display) when s_{howModulusControl} is not 1. You can set that value through CL just like any other number.
Couldn’t stop myself 
Circular Mapping Modulus Controls
Strong disclaimer that my thinking probably doesn’t fully match your thinking, and that’s okay! Lots of possible ways to build this graph, this is just what I came up with. That first folder may be most helpful for you: I imagine taking that top comment and pasting it into the CL to serve as an “initialization” for the graph. (Note that the activity thumbnails won’t match the student screens if you do things this way — you’d still want to update the graph parameters at some point before saving if that bothers you.)
Wow, wow, wow. Way simpler. I’m pretty sure I understand it all. I’m happy to learn by adopting/adapting the code of more experienced geeks. thanks!
You made a nice trig optimization replacing cos(pi/2 -x) with sin(x) … .
Also, I think the mod can be accomplished implicitly by winding around the circle:
sin(mod(n,m_{odulus}) 2\pi / m_{odulus})
=> sin(n 2\pi / m_{odulus})
And, how many other mods are not needed?
f(n)=mod(m_{ultiplier}\cdot n,m_{odulus})
=> f(n)=m_{ultiplier}\cdot n
None of the mods are needed! I left them in as a “just-in-case” measure to avoid floating-point weirdness, even though the values here aren’t likely to run into anything. With a large enough input n, n*2pi / 2pi will be not quite n thanks to rounding errors, so you can start to see cos(n*2pi) diverge from expected values once you start getting big. It takes a while for that to happen, though: https://www.desmos.com/calculator/rzysisg1ju
Yes, none of the geometry needs mods, but displays do. Them’s some big numbers.
I reversed and shaped the hue distribution of distances in the list D
sqrt((2-D)/2)
Yes, sqrt was the winning function so far. It spreads out small values.
I’ve simplified much stuff, but not the tricky CL communication stuff, so far.
Update: Turning displays off was easy as there is a height variable for each section.
Do you mind if I acknowledge you in the thanks section?
I’ve gotten it all to work from CL => THANKS!