# Why does it accept letters after number in math input

I teach on-grade level and struggling math 6 students who continue to argue with me that Desmos is accepting their answer of 3n when the answer is n=3 and I coded it to check the numeric value of 3. Can anyone explain to me either
A) Why Desmos does this - is it on purpose???
or
B) What can I do to code it to stop doing that?

Can you share what you have?

``````correct: eq1.numericValue=14

disableEvaluation: true
``````

Could you share a link to the activity? The devil is often in the details

When you ask it to check numericValue, it will do exactly what you are seeing. If you want it to be exactly 3, you could do something like this using patterns:

``````patterns.number.satisfies("x=3").matches(this.latex)
``````

or

``````patterns.literal("3").matches(this.latex)
``````

I think, for either of those, if they type anything other than 3, it will NOT match.

Thank you. I guess I just donâ€™t understand why a numeric value doesnâ€™t automatically imply exclusively a numeric value.

You could also use:

``````this.numericValue=3 and patterns.number.matches(this.latex)
``````
1 Like

Iâ€™m wondering if it is to allow students to enter something like â€ś3 metersâ€ť and still accept it without having to explicitly code all the variations of units a student might enter.

Thatâ€™s what I would think if it required a space after the numeric value.

For whatever itâ€™s worth I think itâ€™s rather strange too. I canâ€¦ sort of buy the units thing, but not really when other seemingly similar things result in errors.

Yes, thatâ€™s exactly it. Itâ€™s interpreting the letters as unit labels.

In the case that a student types something like 5meters we wouldnâ€™t want to mark then incorrect (if in fact the answer is 5 meters) and erring on the side of allowing more false positives than false negatives leads us here.

One way weâ€™ve worked around it is to evaluate the input as a function and make sure that it evaluates to itself at 0. Patterns are great too, but you need to be careful that youâ€™re not marking a student wrong for a right answer in a different form. If only a number pattern is used, fractions, square roots, exponents, etc will all be marked wrong.

1 Like

I think thatâ€™s a rather big semantic mistake, for the very reason brought up in this post.

Recall that the input is theoretically math, not a text field

``````1xâ‰ 1
``````

Treating it as sorta-math sorta-text is not good.

That units problem is solvable through suffix and would avoid this issue. Just my opinion, but I think shared by others.

I think Jayâ€™s explanation makes sense, though, now that I think about it. If you want to be restrictive, we have the tools to do it in CL, even if you just want to catch students and redirect them. If numericValue started out as restrictive as many (including me) thought it should be, it seems harder to allow more freedom.

I frequently have students enter more than just a numeric answer when Iâ€™ve asked questions with math inputs (even when Iâ€™ve entered a suffix), so this has been useful for me in many instances.

Itâ€™s certainly useful but itâ€™s also inconsistent, which ultimately is confusing both for the student and teacher(iâ€™m thinking in terms of correctness).

Suppose one student enters: `1Â°`. Another student enters `1degree`.
Desmos will accept the second answer as ok but not the first.
And of course if a student tries something that Desmos does not handle well, like `pints`, it will really confuse the student.

The other more subtle aspect is that SI units must have a space between the number and the unit delimiter(so for example `40 m` is correct but `40m` is not) precisely because placing the number adjacent to the unit symbol implies a product, mathematically. When weâ€™re writing things out textually itâ€™s not a big deal but since the field type is latex, this actually is a big deal.

Finally Iâ€™m going to take issue with Jayâ€™s argument about false positives being the lesser of two evils. What if one student enters `1 m` and another enters `1 km`? Are we really saying theyâ€™re equal and that thatâ€™s better than marking them wrong and having a discussion as to why?

I understand why Desmos has gone down this road, and logistically it might be easier to just give this stuff a pass in the classroom when youâ€™re busy helping a number of kids, but I just canâ€™t agree.

1 Like

Standing ovation - YES! This is exactly what I was trying to convey. Thank you!

1 Like

Because itâ€™s formatted as math, it also uses a math â€śitalicâ€ť, not upright, font for that text.

Metric units must be upright font.
3 km
is a valid metric measurement
3 km
is not.

I recognize the reasoning of both parties here, but I have to agree that a numericValue correctness check should be cognizant of excess letters even if some units may be loosely represented in this way.

However, a truly useful feature would be a Math Input that allows for students to enter in their own unit suffix. (I understand some here use a separate multiple choice or text input to allow this but such workarounds are sometimes unwieldy for students. And unwieldy risks a loss of engagement.) Or at the very least, having the suffix snap closer to the input value visually.

I occasionally ponder being able to choose right alignment for inputs (instead of â€śsnappingâ€ť to the suffix).