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).