Automatic correct answer for answers with units about pg

[drgrice1]

Can you attach a minimal working example that gives the error? The PG code that you posted has lots of problems and doesn't work.

One problem in the posted code is that the variable $MU_0 is not defined, and so that makes $B equal to 0. So the correct answer in your posted code is 0 T. In addition, adding m/A to T (giving 0 Tm/A for the answer) does not make the answer correct.

Also, you should not be mixing classic PG code (BEGIN_TEXT/END_TEXT blocks) with PGML (BEGIN_PGML/END_PGML blocks). Just use PGML.

[pkohl]

Thanks for the reply. This is functioning code - we've been using it in a course for two semesters now. $MU_0, for example, is (I'm pretty sure) defined in Constants.pg, which I thought was part of the Webwork default implementation.

I had a little trouble figuring out where to file Webwork bug reports, and I have a feeling I may be in the wrong place. I'm going to ask around a bit. Sorry for the trouble.

[drgrice1]

There is not a Constants.pg macro in pg or in the open problem library, and nothing in pg defines the variable $MU_0. Perhaps you have a local macro that defines that variable?

If this is a webwork2 bug it should be filed here. In this case it is not. However, it could be a pg bug. In that case it should be filed at https://github.com/openwebwork/pg/issues. Although, for this sort of thing it is best to start by posting on the webwork problem authoring forums (https://webwork.maa.org/moodle/mod/forum/view.php?f=3) to see if you have a mistake in your code first.

[Alex-Jordan]

I have boiled this down to a MWE. There are at least two bugs. One has to do with the zero tolerance level, but I have not chased it down in code yet. Another bug I found while looking at this.

DOCUMENT();
loadMacros(
    "PGstandard.pl",
    "PGML.pl",
    "MathObjects.pl",
    "parserNumberWithUnits.pl",
);

Context("Numeric");
$A = NumberWithUnits("1.1*10^-2 T");
$B = NumberWithUnits("0.9*10^-2 T");

BEGIN_PGML
[$A] = [_]{$A}{10}  (Type in [|0.011 Tm/A|]* and it's "not a number with units")

[$A] = [_]{$A}{10}  (Type in [|0 T m/A|]* and it's not accepted, good!)

[$B] = [_]{$B}{10}  (Type in [|0 T m/A|]* and it is accepted, bad!)

END_PGML

So one issue is that for some reason answers where the unit is Tm/A are not recognized as numbers with unit.

But the issue being reported has to do with the 2nd and 3rd answer blanks. An Angstrom is 10^-10 meters. I set $A and $B to straddle 10^-2 meters. And the defaiult zero tolerance is 10^-12. I don't understand it yet, but this doesn't seem like coincidence.

[drdrew42]

Further complications (see screenshots):

• For answer 1: 0.011 Tm/A results in "not a number with units", no answer preview.
• For answer 2: 0 T m/A is "incorrect"
• For answer 3: 0 T m/A is "correct"

• Change answer 1 to 0.011 T m/A, which is now marked "incorrect", no message.
• leave answer 2 unchanged, but now gets marked "correct"‽
• answer 3 is still marked "correct"

[drdrew42]

@drgrice1 is correct, this should be moved over to PG/issues

[Alex-Jordan]

I transferred it to PG. It was webwork2 #1815, now it is pg #740.

[drgrice1]

A few things that I have seen so far on this. It happens with and without MathQuill enabled. It is not due to the new MathQuill parsing, and there isn't a regression introduced by that either as it happens with previous versions of pg as well.

Part of the issue seems to be in the regular expression parsing in the splitUnits function in lib/Parser/Legacy/NumberWithUnits.pm. For the first answer that is entered as 0.011 Tm/A the splitUnits methods returns $num and $units both undefined. That is the reason for the message Your answer doesn't look like a number with units.

Another part of the issue is that the NumberWithUnits objects are not "stateful". The first and second answer both use the $A object for the answer. NumberWithUnits objects can't handle evaluate calls. This is actually a known issue. See the todo test at the end of t/units/basic_parser.t.

The final part of the issue, that is the original issue here with the answer being marked correct when it shouldn't, I haven't figured out what is causing that yet.

[drgrice1]

Actually, looking further at the Tm/A part of this, units in general are not designed to be able to handle multiplication. The same things happens with a Newton meter. You have to type N m or N*m for that to work. So I am not sure that is technically an issue according to the design of units in pg at this point. That would be a feature request for future improvements to the way that units work.

[Alex-Jordan]

Confirming some things Glenn says (and I should have brought up earlier): OP is using Runestone hosting, still using version 2.16, and not using MathQuill.

[Alex-Jordan]

So I see in Parser/Legacy/NumberWithUnits.pm there is a subroutine adjustCorrectValue and it has this comment nearby: Fix the correct answer so that the value matches the student's units.

So it's "fixing" 0.009 T (the official correct answer) to make the units be T m/A. That makes the effective correct answer be 9e-13 T m/A, with numerical part smaller than the zero tolerance. And that's how you get entering 0 T m/A to count as correct.

At first glance, it feels like the wrong choice to "fix" the canonical correct answer instead of "fixing" the student's input answer. Maybe there are other bad things that could happen if it goes the other way. Can we imagine that?

[Alex-Jordan]

Note that, as Pat says, this bug opens up a way for students to get any NumberWithUnits answers accepted as correct as long as you have the basic dimension correct. Say the correct answer is 50 kg for example. You can just enter 0 kg m^2/A^2 and it will be accepted. Or 0 kg^6/g^5. Or 0 kg parsec/m.

[drgrice1]

Clearly this needs to be fixed! I think that adjusting the student answer instead of the correct answer would work. I am not sure how hard it is to make that change though.

[pstaabp]

This was fixed in #740