# Inequalities and Desmos

Some of the most common questions we’ve received recently are about how to interpret
student responses when the prompt asks for an inequality. Up until very recently, our
response was, “Here’s a workaround.” These often involved tricky conversions to
piecewise equations, like in “Point Collector: Lines,” or to regressions, like in “Domain and
Range Introduction.” We heard you and felt your struggles. Now, we’ve replaced those
bandaids with a cure. Introducing . . . *parseInequality*!

# What Is parseInequality?

If you’ve worked with *parseEquation*, *parseInequality* will feel very familiar. *rhs*, *lhs*, and
*differenceFunction* are there, along with a few additional members to help with direction
and strictness. Here’s a breakdown of everything it can do:

`rhs`

| Gives you the right-hand side of the inequality as a string.`lhs`

| Gives you the left-hand side of the inequality as a string.`differenceFunction`

| Creates a function by subtracting (greater) - (less).`isStrict:`

| Indicates when an inequality is strictly greater or less than—none of that “or equal to” business.`isLeftGreater`

: | Indicates whether or not the left side of the inequality is greater than the right.

For a more detailed explanation, visit the Computation Layer documentation.

# How Do I Use It?

Like other functions, parseInequality helps us with two needs:

- Showing what the student entered.
- Determining if the student’s answer is correct.

Before we dive into each of those, let’s take a look at differenceFunction. We’ll be using it for both graphing and correctness.

## differenceFunction

Like in *parseEquation*, *differenceFunction* in *parseInequality* makes a function by
subtracting one side from the other. The big difference is that while using parseInequality,
the function is created by subtracting the “less than” side from the “greater than” side.
This is a notable and very useful difference because it makes the solution set become all
of the values that make the function greater than (and sometimes equal to) 0. Check out
this activity to learn more:

## Graphing Inequalities

differenceFunction makes graphing inequalities easy . . . Two sink/source pairs easy! Read on or check out a video tutorial to learn more.

- In the graph scripting window, use a function sink to bring the differenceFunction
into the graph:

- Also in the graph scripting window, make a number sink to create a variable that is
1 when the inequality is strict and 0 when it is not:

- In the graph, plot two inequalities. Remembering what was stated before about the
solution set of differenceFunction, graph all of the values where f(x,y) > 0 and f(x,y) ≥
0. (Why f(x,y)? See here)

- Finally, attach a condition to show only one of the graphs using the number you
created in CL. Make the solid line show when the variable equals 0 and the dotted
line show when the variable equals 1.

Inequalities on a number line work very similarly, but with a few differences for visuals in the graph.

- Follow steps 1 and 2 from the previous instructions. For this example, try labeling your function “f” and your strict variable “s”.
- Single-variable inequalities are actually much tougher to plot than two-variable. That's because the boundary isn’t built into the graph of the function (in the case of two-variable inequalities, we have the dotted or solid line on the graph itself). Here you’ll want to paste this graph into your graph component. You can do so by copying the URL of the graph and pasting it into an empty line in the graph component.

See both examples here.

## Correctness

Correctness for both one- and two-variable inequalities is very similar. In both cases, you’ll need check for the following:

- The boundaries of the keyed inequality and the student inequality must match.
- A value (or coordinate pair) in the solution set of the keyed inequality must be in the solution set of the student’s inequality. If there are multiple “zones,” you may have to check values in each of them.
- Strictness must also match. If the key is strict, make sure the student input is strict, and vice versa.

I walk through an example of each in this video:

*parseInequality* is still brand new, and we’re still exploring fun and interesting ways to use
it. We’re also still looking into best practices and style for its implementation, especially
around correctness.