Day 9: Maybe I Should Just Stick to Dragging and Dropping

I'm still watching the first of Jay chow's webinars. One thing I know for sure is that having the ability to pause & re-watch is huge. (Hello flipclass.)

I'm trying to get my head around that example on screen 16:

It's easy enough to get it to automatically graph whatever rule the student types in, but I wonder:

How could I get it to only graph once the submit button is pressed? It doesn't seem to fit the When-otherwise scenario. Taking Jay's advice on writing it out in english first: When input2 is submitted then inject input2 into the graph otherwise do nothing. For the do nothing - just make the otherwise part "Type in the equation of the line that goes through these points."  I tried typing "when" and seeing what the error code told me. It said it was expecting otherwise, but then when I put that in it said it wasn't expecting that...

Went back to trying exactly what Jay was doing with the T variable, and I got it to work. Unpacking the whole variable idea again. We needed T in the graph so that as it increased in value (which is done by moving the T slider to the right), the domain of the function f being graphed got wider, so the curve appears slowly from left to right. Clear, very clear. And we needed to connect that T value with the CL by calling a variable by the same name, so that however much that variable T is in the CL, that's how much T in the graph is. So in effect, changing the value of the variable T is equivalent to moving the T slider. And if we want to increase the value of the T variable in the CL, we make it equal to the number of seconds since the submit button was pressed. Got it.

Tracing the path of T - it starts having a value on submit, which gets sent to the graph, then overrides the value of T on the slider.

Jay says: "The basic structure of CL is we create something (the sink) FROM something (the source)."  This is a good way to think of it.

Screen 20: Noticing something that has happened before. I am certain I've typed exactly what Jay typed but I'm getting these brackets (I've highlighted in grey) immediately after the timeSincePress

It doesn't seem to be a problem though, and the error was due to me mistyping timeSincePressed - shouldn't have had the -ed at the end.

I tried to make the second "when" include the current coordinates but it didn't work. Sigh.

Back to Jocelyn's collection. I'm going through it again from the beginning, one by one, to see if I can recreate them.

On example 2, the correct script was simpleFunction(table1.cellContent(1,2),"x") which also works without the x at the end. But I don't get why we don't have to put .latex anywhere like we did for example 1. The only difference between this one and example 1 was that there are 3 functions to type instead of 1, so we're using a table this time.

Maybe it IS better if I just drag and drop other peoples' stuff....

Day 8: OHHHH SO THAT'S WHAT TIMESINCESUBMIT IS FOR!!!!

Next, I'm going to look at Jay Chow's Webinar 1 and the accompanying Desmos activities. Audrey's on a roll, baby!

I've decided that, for now, I'll abandon my so-far strategy of looking at the DA in preview mode and trying to unpack the CL before peeking at it, and instead I'm going to just watch Jay's webinar and let him unroll these things. He's a really great CL-er and he's made a lot of webinars, so he knows what he's doing.

Comment on how he is doing the webinar: First there are some screens for us to interact with, after which I see that Jay is using the screens of a DA as a presentation in and of itself - he's sharing his screen (and of course he has turned on the Anonymizer to make a safe environment), and clicking through the DA screens. I like that. Imma do that!

Screens 1-4:
We are asked to input something and nothing happens as a result. I think I see where this is going. 

At 9:38, Jay makes the case for using CL by contrasting activities without CL and with CL. (we just did 4 screens without and immediately felt the need for CL - Also this reminds me of how Christopher Danielson (@trianglemancsd) presented CL last year at the Desmos Fellows weekend (cohort 3). He said - I'm going to make you unhappy, then I'll show you something that will make you happy.)

Without:
When your students type in the input it's a static entity
Action buttons don't work
Things don't work together

The first example we are trying to add CL to is one in which we want the student to input an expression that evaluates to 4, hit the submit button, then get feedback. The feedback will depend on whether or not it's correct.

Around screen 14, I see Jay using the snapshots feature, also while he is sharing his screen. I've never used that feature, so it's nice to see it in action.

Aha at 25:01 I was wondering why the input expression hadn't been evaluating as it usually does - because it's been disabled with the built-in disableEvaluation, behind the input component. The full script is disableEvaluation: true. And that's why the gearbox for the input component is green, that's the script in there.

37:35 I see the effect of the ${} - it turns static text into dynamic text. No variable needed. Jay recommends we write out in english what we want to do BEFORE we write any script. Very good idea.

Next example screen 16: Students see a graph with 2 points on it and they are to type the equation of a line that goes through those two points, submit, and get feedback.

At around 47:00 Jay is using someone's suggestion to do two things - put the typed equation into the expresion list on the graph, and then graph it. I thought that as soon as an equation is in the expression list, it's automatically graphed? Why do we need to ask it to graph it? This turns out to be that we want the graph to be revealed slowly, as a result of additional interaction from the student. See "Whoah" below.

Also, I see a lot of auto-complete happening as letters are typed - very helpful.

To make a function, use the built-in function thingy? In the graph gear, the sink is indeed function: ("f") but the name f has already been typed into one of the graph boxes. Needed to label the input and use latex as source type.

At 52:04 script at this point is

function("f"): input2.latex

but there is an error message:

Sink "function" expects a function but got a string.

So input2 is currently being interpreted as a string, even though the source data type is latex. I'm not sure why that is happening. But based on examples I've seen from Jocelyn's collection, I bet it needs simpleFunction maybe? Yup.

Now it's:

function("f"): simpleFunction(input2.latex)

Jay: "I'm gonna make that function from the latex...in this case it's gonna look for x"

So I'm noticing a new level here - in input2.latex, we still have the syntax sourcelabel.sourcedatatype but it's in brackets that go with the built-in function called simpleFunction. And we need this built-in because otherwise the source (called input2, which remember is the equation typed in by the student) will be interpreted as a string (text), and the graph sink doesn't accept that type of data.

This made me go back to the CL doc and look up Graph. Question - what do the subheadings "Sources" and "Sinks" mean here? That these are all the types possible when the graph is a source? Or all the types possible for the graph's sources when the graph is a sink? 

Back to Jay. Next step is to stop it from graphing until submit has been clicked, so we'll need to use that input2.submitted thing. Last time we used that, it was part of a when-otherwise structure.

WHOAH.

So it's not at all like last time. It's that as soon as the student clicks submit, the curve is slowly revealed as the seconds tick by. To do this:
1. A variable T (for time) had to be introduced into the graph, and its values restricted to x < T , which means that as you move the T slider, the graph is slowly revealed from left to right. (This was later tweaked to x < T - 10 to make the graph start showing at -10 instead of starting at the origin.)
2. To link the CL to the T in the graph, a variable T had to be defined in the CL. The variable was defined in one of the familiar ways like this:

number("T"): timeSinceSubmit 

which kind of makes the submit button a source for the variable T. As soon as that button is pressed, a timer is started at 0, so there's now a variable T whose value is 0, and as the timer continues, the value of T increases. This makes the line start graphing on the left, and slowly be completed. So a student doesn't know right away if they're right, but they can pretty much predict, and even change their answer if they want.

I HAVE BEEN WONDERING WHAT THE HECK THAT TIME-SINCE-SUBMIT WAS ALL ABOUT FOR OVER A YEAR!!! It makes animation happen as soon as a student clicks the submit button wut!!!

Stopping at 58:00 because I need to step outside and look at how this learning has unfolded so far. My ultimate goal is to help others learn this, so I need to figure out what worked for me.

How I’ve learned so far:

Read, looked at examples, re-read, tried things, and re-re-read, all the while documenting observations and questions on my blog. Some of the questions got answered in the same day, in which case I wrote the answer in italics next to the question. Those that didn’t, I bolded (thanks for that idea @geonz.) Some of those bolded questions I remembered on later days and went back and answered, but others I picked up later after deliberately re-reading my posts. The bigger ones, I just put a note on “answered in later post” and put that whole thing in a subsequent post.

Next I watched Jay Chow's webinar. As I watched, many questions were answered, (what are ${} for ? – it changes something from static text to dynamic text, just like objects in GeoGebra) and many observations were confirmed (when you select latex in an input it automatically displays the math expression properly and evaluates it without any need for CL – also found out how to turn it off!).

But here's what I noticed about how I learn:

I needed to have already asked those questions or observed those things in order for them to have meaning for me as I watched the webinar.

That probably makes me...human.

Learning CL Day 7: Coolcoolcool

First I'm going back over my previous posts to check for unanswered questions, which I already went back and bolded a few days ago so I could find them easily.

On day 1: I wondered about the word script in this line:

content: note3.script.greeting

and it reminds me of something I wondered about yesterday, and that is the seeming interruption of the sequence sinktype: label.sourcetype with words like script, or simpleFunction.

On day 2: I wondered about the example under the heading "Sources" involving latex and variables, and I remember starting to feel very anxious right around then. Here's what I said:

content: "
You entered: ${l}
which evaluates to: ${v}"

Earlier in the script the variables v and l are defined:

v = exp5.numericValue
l = exp5.latex

and both those variables belong to exp5, which is the name of the input. So does this mean the exp5 is the source here? I typed 4^2 into the input and it got injected into the note AND the input. Soooooo the input is the source and the sink here?

Now I think I know a bit more about what was happening there. So hmmm. What gets typed into the input (labelled exp5) is displayed in two places - obviously right in exp5, but also in the note. So it seems true that the input (exp5) is both a source and a sink. But whatever gets typed is also a source for the note, which explains why the script is behind the note's gearbox. But now I'm wondering what is making the 4^2 to be displayed properly AND get evaluated right in the input box? I did an experiment and deleted the note completely, which means there is no longer any CL or script. I typed 4^2 and this happened:

Which tells me that the lovely folks at Desmos take care of that without any CL being necessary. As soon as you select f(x)math for a note, it interprets what you type as latex, and it evaluates it. 

I know that I knew that already on some level, but NOW I REALLY KNOW IT.

On day 3: This is where I first encountered simpleFunction. Hopefully today its placement in the script will start making more sense.

All the other days had no open questions, so I'm ready to move on.

I feel like I need to re-read the CL doc, because I had stepped away to try other things out and immerse myself in examples. Time to go back and un-overwhelm myself, and to get a better handle on that secret sauce: Variables.

Variables:

So you can call a variable anything I guess, and you define it by what's on the other side of the equals sign. You can have something in quotations, like:

greeting = "hello, world!"

Or it can be whatever's in another component (which is the source for that variable), which has a label, like:

v = exp5.numericValue

in which case we need to also specify the data type of that component (or source) that we want to extract, because there are other types, like:

l = exp5.latex

You can also define a variable right inside the script for a sink, without any equals sign, but using brackets and quotations, like this:

number("m"): exp1.numericValue

which was in the guess-the-slope-of-this-line example, but in order for things to work, the variable m had to be in the graph itself, as y = mx. So one way or another, there has to be an equals sign involved in the definition of a variable.

Another new word I see in this section is "keyword", in this example:

I wonder if "keyword" has a specific meaning in the CL syntax world?

Also I still feel unsure of when a variable is needed, and when it's not.

Functions:

Aha. "We have a few built-in functions for interpreting sources and converting between data types." Perhaps this is where those seeming interruptions (script, simpleFunction) come in. From the examples, it looks like these built-in functions go into the script after the equals, then are followed by brackets, which contain the expected sourcelabel.sourcetype. However, all the examples are variable definitions, so I'm wondering if these built-ins can be invoked for sinks as well?

Conditionals:

This seems more familiar, maybe because I've recently been putting a lot of Conditionals in my GeoGebras, which uses the If-then-else structure, equivalent to when-otherwise. Did the Try it preview first. The student enters a number in the input, and  a message, entirely text, no numeric part, is immediately displayed in the notes above it. But what message is displayed depends on the number input. So let's see if I can predict any of the the script:

The source is the input box, so that must be labelled exp1 or something.
There must be a variable defined for whom the source is exp1, like n = exp1.numericValue .
f(x)math must be selected on the input
There must be script in the note's gearbox something like content."text message" and there must be a few when lines for different values of n.

Checking: The input is labelled "number" instead of note1, ok.
I got the variable definition syntax right.
f(x)math is indeed selected.
I was right about the content dot part and the whens. Yay! Also, the various text messages are enclosed in quotation marks, and a built-in "isUndefined(n)" is also there to display nothing when whatever was typed in wasn't a number.

Getting somewhere, coolcoolcool!

Tomorrow, I'll start watching Jay Chow's webinars.

Learning Desmos CL: Day 6

I just took another look at Andrew Knauft's tweet and I didn't even realize before now that it had a variable in it - in fact it SAYS "variable assignment". My brain doesn't register stuff until I've come around to it I guess. Variables are, I think, the secret sauce.

I'm going to try this out but first predict what it does. In this activity, a student will be prompted to enter a number in an input component (labelled input1), and once they do, a note will display the message "Your number was" followed by whatever number they input. These two lines of script go together as sink and source, which is one thing that's been sort of confusing me. I thought there always had to be two lines of script, one about each, but up till now, that hasn't always been the case.

Tried it, didn't work at first because I forgot to check the f(x) Math option in the input, now it works on screen 5 of this puppy.

So we needed a variable here because not every student will type in the same thing, but we want whatever they do type to be immediately displayed. But why didn't we need one for, say, the guess-the-slope-of-the-line activity? Was it because the slope was being sent to a graph as opposed to a note, and the graph sort of takes care of the variable part of it with the y = ax thing? And also this part of the script number("a"): which seems to be defining the variable AND the sink at the same time?

I notice that in the variable assignment, the structure is similar to a sink assignment, in that, after the equals sign, it names the component that will be the source, and its data type.

I'll continue looking at Jocelyn's collection now.  I've already looked at and blogged about the first 3-4 so far but I'll look again with new eyes. I'll also try a new strategy of looking at the preview first, then figuring out all I can about what the script must have been. Eg 1 preview:

3 components, a graph, a note, and an input. Whatever is typed into the input immediately shows up on the graph. So the source is the input and the sink is the graph. There must be script in the graph's gearbox. The script must include sinktype: note1.sourcetype. Also since the equation I typed is being displayed properly and not as y = x^2, which is what I actually typed, it must be that what I type is being interpreted as latex, so the f(x)math option must have been selected in the input, and the sourcetype must have been latex. I'm not sure what the sinktype would be. Also in the actual graph there must be something about a variable that is the name of the function being graphed?

And after checking: In the graph the function has been called f(x), so that's the variable definition. The input has been labelled input1. The script is where I expected it to be, in the graph's gearbox. The script is one line:

function("f"):simpleFunction(input1.latex)

So the sinktype was function, it includes the variable f in brackets and quotes so that it references which variable we want going into the sink, and the source type is latex. The only part that surprised me was the simpleFunction part. Why does that have to be there? And since it's after the colon, does that mean it's a sink or a source type? I expected a label to follow the colon, which there is one but not immediately after.

Back to the CL doc, where I'll look up simpleFunction (again) in the table under Graph.

I found it but only under function, and under the Sinks part. It says:

function(identifier: string)Sets the output of simpleFunction() to a variable defined in the graph.

The accompanying example is:

# Get the latex string from "equationInput" and assign# it to f in the calculator.

function("f"): simpleFunction(equationInput.latex, "x")   

which is virtually identical to the one in Joce's eg except for the "x" part, which I seem to recall is something that if it's not there, is assumed.

I also looked under "Functions" and found simpleFunction. It says:

simpleFunctionTakes a latex string and returns a function which can, for example, be passed into the function sink of a calculator.The first argument is the latex string, and additional arguments are The names of the variables to treat as input variables (defaults to)one-variable function in terms of x if not specified

Aha that's where I saw the bit about the x.  Anyway, so it appears there are other pre-defined operations, like simpleFunction, that do additional things if you put them into the script. I don't know how to put this into my syntax structure from day 5. Does it always go right after the colon/equals sign? Is it a source or a sink or a datatype or something else altogether?

I really need to come up with some kind of a diagram to help me order things in the script, and I suspect others who are struggling with CL might too.

Learning CL: Day 5

It's amazing how many times I have to read, re-read, re-re-read before things start to sink in. (Haha sink get it?)

Syntax/structure I've gotten so far:

1. Label all components you intend to use as a source eg note1, exp2, table1 etc
2. Script goes in the gearbox of whichever component you want to be the sink
3. Script starts with the data type for that sink, which could be a word like content, number, function, cellContent.....etc then that is followed by a colon
4. Next you put the name of the component that you want to be the source eg exp1, note1, table2 etc, followed by a dot
5. After the dot you specify the type of data you want to extract from the source (bc it could contain more than one type of data) so that could be numericValue, content, latex, cellContent(1,2) etc

So a script starts out talking about the sink, then ends talking about the source. The script says "This is what's going here and this is where I'm getting it from."

To confirm this, I've gone through a few samples of CL from the CL doc and from Jocelyn's collection, to trace this pattern. (Some of these examples have um other stuff besides what I've listed above):

Data type of the sink at the beginning of the script, followed by a colon:

The name of the component from which something will be extracted, followed by a dot:

In the first example, what's in the quotation marks is, I guess, the source. This must mean that no matter what happens, Hello! I'm the computation layer! is what will be displayed. Similar to the third example, in which the variables m and b will only ever take on the values 1.5 and 2.

 Finally, the type of data being extracted from the source:

I'm seeing a LOT of examples involving variables, in which instead of a colon, there's an equals sign. There must be something to this variables thing. I don't think you can really do much without variables.

That's it for today. Back on vacay.

Learning CL: Day 4

After a brief time away, today I resume my CL journey.

I started out by re-reading my own posts, and suddenly had the urge to start trying things out myself, starting with recreating the "guess the slope of the dashed line" activity. Made me see a few things:

1. Why there has to be a y = ax on the graph screen, so that the slope (a) that the student inputs gets sent to that value in the graph.
2. I allowed the slider to be created, and it didn't seem to make any difference. The y = 0.5x graph shows up no matter what, but the y = ax one only shows up once a value for a has been input.
3. The script gave a warning because I hadn't checked the f(x) math box on the input. Then I was allowed to use the numericValue part. Not checking that makes the input component a text, so the type wouldn't match.

I then did a few more screens with a similar example right away to reinforce all the things:

number("a"): exp2.numericValue  is the script inside in the graph's gearbox. number("a") means that some part of the graph is expecting a number it's calling a, exp2 means it will get that numerical data from a component called exp2, and .numericValue means that the type of data is a number, not text. Worked.

Just not sure why we need to say number at the beginning and then numericValue again at the end. Going back to the CL documentation.  Under "About the CL Language", it says that "every sink expects a specific type, and every source emits a specific type." So in the examples I made with the graphs, "number" is at the beginning to specify that the graph component is a sink that expects a number. Note: Other words you can have at the beginning of a script are string, or boolean. (What about content, isn't that a possibility too? yes - see the table with the heading "Note")

Under "Sources" it says "each component has a different set of sources". So a component can have more than one type of data in it - in the example here two types come from the same component, one being numericValue and another latex.

It seems that the word "number" at the beginning of the script refers to the sink's data type, and the numericValue at the end refers to the source data type.

So what comes after the dot is the type of data we are extracting from a component. There are tables with headings "Sources" listing all the things that could come after the dot, and others with the headings "Sinks" listing all the things that could come before the colon.

I just remembered something Andrew Knauft sent me on twitter:

I managed to find this picture I made way back when. Just a taste of the vocabulary! pic.twitter.com/AL99O2VTE8

— Andrew Knauft (@aknauft) July 19, 2019

There's that sink at the beginning before the colon or the equals, and the source at the end after the dot. And the component name in the middle.

Starting (slowly, slowly) to see a structure.

Learning CL: Day 3

Yesterday ended with a whimper. I became thoroughly confused and discouraged. Again. I think I've come to the end of the big picture explanations on the Desmos CL doc. The rest is a huge list of scripts that fascinate and terrify.

To keep track of open questions, I'm going to bold them.

Today I'm going to look at Jocelyn Dagenais's (@jocedage) Intro to CL collection that he very graciously shared with me on the train back from OAME this May.  By the way, OAME (Ontario Association of Math Teachers) puts on one heckuva great conference. Next year it'll be in Oshawa, and the lineup is just stellar.

Example 1:

Shows me one major advantage with CL, over using just the regular activity builder, is that on a single screen, you can have a graph AND an input, and the graph is not static - what the student types in the input immediately shows up on the graph. In the regular activity builder, that could only happen if the graph was the only thing on the screen, and students could get things to appear on the graph as usual with the Desmos graphing calculator. (The problem with that is that sometimes they accidentally got things to disappear too tho!) In activity builder, as soon as you'd add any other component besides the graph to a screen, the graph became static to the students. With CL, they can type their equation in the input box, and see the graph on the same screen, and there's no chance that they can inadvertently delete anything from the graph, which happened a lot.

In screen 1, there is a note (with instructions), an input (with the latex option selected), and a graph. They're all labelled - note1, input1, and graph1. The script is behind the graph:

function("f"):simpleFunction(input1.latex)

I guess that since the script is in the graph's gearbox, that means that whatever source is specified in the script will automatically be linked to this graph? In other words, there's no need to specify that the input is the source? Is there ever?

Anyway, I get that the : indicates that the graph is something that will receive (bc it's a sink) data from somewhere else, and where it will receive data from is indicated by the "input1" part. The dot latex specifies the type of data. For the simpleFunction part, I looked back at the Desmos CL doc and found this under Functions:

simpleFunction

Takes a latex string and returns a function which can, for example, be passed into the function sink of a calculator.The first argument is the latex string, and additional arguments are The names of the variables to treat as input variables (defaults to)one-variable function in terms of x if not specified 

So that explains why "simpleFunction" is there, it's giving instructions for what to do with the argument. (argument here must means what's in the brackets).  "The first argument" would be "input1" and that's what students are typing into the input box, which is being interpreted as latex bc Jocelyn selected that when he made the screen. This script says to put whatever the student typed in note1 into the graph, and graph it.

Did the graph and the note need to be labelled here? They're not referenced in the script. No they didn't - I just deleted those labels and all still worked.

Example 2:
Also has a graph and a note, but instead of an input, a table, labelled graph1, note1, and table1. The table allows for 3 different functions to be typed in, and so 3 functions to be graphed at the same time. The script is again behind the graph:

function("f"): simpleFunction(table1.cellContent(1,2),"x")

function("g"): simpleFunction(table1.cellContent(2,2),"x")

function("h"): simpleFunction(table1.cellContent(3,2),"x")

The "cellContent(1,2)" must be a data type and also point to that particular cell in table1. It's the source for which the graph is the sink. So I don't need to specify anywhere that this is a source, it's understood by the simpleFunction syntax I guess?

The x would be the "additional arguments" mentioned under "simpleFunction" above. Not sure why it's in quotation marks. This looks different not only because it's a table instead of an input but also because this time the latex wasn't selected by Jocelyn, although it doesn't appear to be an option anyway with tables? So the data type isn't latex. I don't understand why then, when I, as a student, type x^2 into the cell, it displays not as x^2 but in the proper superscript notation? Played around with a sandbox activity - each column of the table has a pull-down menu, where you can toggle between "format as text" and "format as math". The initial default is math.

I also noticed if I click on "edit graph" to see the actual graph (I'm in teacher mode), that the first 3 rows of the expression list have got f(x), g(x), and h(x)  typed in them, but the orange alert triangle is showing. If I remove those 3 rows, the graphs no longer show up when I type in a function as a student. Same is true of example 1, didn't notice that before. So in order to use the graph as a sink I need to label the row(s), kind of like the table cells were labelled.

Example 2.1:

Similar to previous example but allows for implicit equations, like conics, to be entered into the table cells. The script looks very different though:

eq1 = parseEquation(table3.cellContent(1,2))

eq2 = parseEquation(table3.cellContent(2,2))

function("f"): eq1.differenceFunction("x","y")

function("g"): eq2.differenceFunction("x","y")

The first 2 lines define variables eq1 and eq2 and they are whatever is typed into the table cells. Looked up parseEquation: 

parseEquationTakes a latex string, e.g. "2x+y=1" - and returns an equation object

While looking through the CL doc for "differenceFunction: I saw this:

allowEraser

Sometimes you only want students to be able to clear, not erase. Set this to false if that's the mood you're in.

They crack me up those Desmos folks. Ok so I differenceFunction says

differenceFunction

simpleFunction representing for (lhs) - (rhs) of an equation. Useful for setting equal to zero to test or plot 

Sooooo hmmmm. This may be where I stop today. This must be what my students feel like when they say - I can follow when you do it Mrs, but I know I couldn't do it on my own. But it definitely helps to have these examples, and the CL doc list. Today was better.

I'm off to Austria for a week or so, and it's highly unlikely that while I'm there I'll be computation layering, especially as I'll be at a GeoGebra conference, and learning all kinds of GeoGebra stuff there.