*click this link to see a Desmos activity that demonstrates the code used in this post*

One of the coolest ways to utilize Desmos in the computation layer (CL) is to be able to visualize student answers on the graph. I’m going to show two approaches to this: a direct approach, and indirect approach.

## the direct approach

The most straightforward situation that you would use this feature would be for a student to enter an equation in a “Math Input” box and for it appear on a graph. The general setup would involve a “Note,” a ‘Math Input,” and a “Graph” box like this:

To do this, you’ll go to the graph CL and use the differenceFunction to evaluate the equation. differenceFunction subtracts the left side of the typed equation from the right side of the typed equation. The code in this example would look like this:

`function("f"): parseEquation(input1.latex).differenceFunction("x","y")`

This defines a function *f* that subtracts the left side of the input1 equation from the right side of the input1 equation.

The next step would be to click into graph1 itself and type the following code in the first line of the graph (just as if you were doing it in the graphing calculator):

`0=f(x,y)`

Because *f* is a function that subtracts the left side of input1 from the right side, this graphs all of the points where the equation is true. Now any equation that you type into the Math Input will be shown on the graph.

## using variables other than x and y

The Desmos graphing calculator is pretty finicky when it comes to variables, but you can create graphing activities using variables other than *x* and *y* using the same general setup.

For the code that we put in the graphing later CL, instead of defining the variables in the differenceFunction as “x” and “y”, you would define these as other variables. For example, if you wanted to use *a* and *b* as an alternative, you would type:

`function("f"): parseEquation(input2.latex).differenceFunction("a","b")`

This defines *a* as your output variable and *b* as your input variable. Counterintuitively, the input in the actual graph will stay the same:

`0=f(x,y)`

Once you’ve entered those two lines into your graph, you can type equations with new variables and it will interpret them as the input and output in your graph:

## a workaround if parseEquation won’t do

One workaround that I’ve used in certain circumstances is to ignore trying to translate a computation to the graph. Instead, if an input is correct I will use a “number:” defined in the graph CL to trigger the correct graph.

I use this frequently with statistics to show a best fit line. Rather than having students spend their time populating a table in the Desmos calculator and trying to find the line of best fit, I will prepopulate the graph in the graph and make the best fit line only appear conditionally when they type the correct equation in the input.

To set this up, I define a number in the graph CL:

`number("z"): when input3.latex="y_{1}\sim mx_{1}+b" 1 otherwise 0`

This defines a number *z* that is equal to 0 unless the correct Latex is entered (note: using Latex for correct answers is generally a poor idea since it must be typed as an exact match – although in this circumstance it has been pretty successful).

Then, in the actual graph, I create the table, find the best fit line, and then restrict the best fit line to show only if the number *z* is equal to 1. Like this:

This is a workaround to use sparingly, but in the right situation may be useful. When I’m stuck, sometimes I find it useful to give students the appearance that a computation is being made while also saving me the trouble of trying to code something beyond my capability.

## caution: don’t use rawExpression

A last word of caution about the deprecated feature: rawExpression. There are a few posts in the CL support forum that recommend using the rawExpression function to graph inputs (rawExpression translates an input directly as typed into the graphing layer). This is super easy to use and was allegedly a little wonky causing Desmos to deprecate the function.

Why shouldn’t you use it? Because it was deprecated any activity that uses that command cannot be copied (which is important if you’re sharing your activities with others). I say this from personal experience as I am still rewriting activities from when I didn’t know better.