WeBWorK Problems

num_cmp problem with lb, lbf when answer is in N, kN..

num_cmp problem with lb, lbf when answer is in N, kN..

by Ever Barbero -
Number of replies: 8
I have a problem with 
  ANS(num_cmp($Vmax, relTol => 2, units=>"kN",));

kN is a unit of force, not mass. 
If the student responds 2000 N, WebWork Agrees, as expected. 
If the student responds 449.6 lbf, WebWork tells the units a wrong. Why? (See http://www.endmemo.com/sconvert/knlbf.php)
If the student responds 449.6 lb, WebWork agrees, which is wrong, because lb is a unit of mass. The unit of force is lbf.  

Next I set up a test problem with 
  ANS(num_cmp($Vmax, relTol => 2, units=>"kg",));

kg is a unit of mass. 
If the student responds 4.4 lb, WebWork tells the units a wrong. Why? 
If the student responds 4.4 lbf, gracefully, WebWork tells the units a wrong.

May be I am missing something? ...
 
In reply to Ever Barbero

Re: num_cmp problem with lb, lbf when answer is in N, kN..

by Alex Jordan -
In the Imperial system, a pound (lb) is a unit of force, not mass. I've never seen the "lbf" you mention, but I guess it stands for "pounds of force". To me this is redundant, because pounds do measure force already.

"lbf" is already in the unit parser, but it means "foot pound", a unit of energy. I just saw this by looking here: https://github.com/openwebwork/pg/blob/master/lib/Units.pm. Perhaps that is a mistake, and "lbf" should just mean the same as "lb". And "ft lb" should mean "foot pound". Certainly this Wikipedia article would suggest that is standard. https://en.wikipedia.org/wiki/Foot-pound_(energy). (It also shows use of "lb_f" for "pounds of force".)
In reply to Alex Jordan

Re: num_cmp problem with lb, lbf when answer is in N, kN..

by Ever Barbero -
I fixed the Wikipedia article and added a ref. to a book, now in the 10th edition, that has been used to train Mechanical Engineers for over 50 years. I am 100% sure lbf is force and lb is mass. Only on earth (g=9.81 m/s^2) they are numerically equal and thus confused. When you buy a pound of meat, the scale measures the gravitational force but really you are interested in the protein and fat, thus the mass. At the moon, the same steak weight less, but has the same mass. For everyday life on earth the distinction is mute, but in aerospace engineering, it is crucial as g is no longer 9.81 once you leave earth. 
In reply to Ever Barbero

Re: num_cmp problem with lb, lbf when answer is in N, kN..

by Alex Jordan -
This sounds like a convention that is familiar to you, but not to me. Every physics course I ever took in high school and college used "lb" as a unit of force. And consequently used "lb/in^2" as a unit of pressure, used "ft lb" as a unit of torque, etc. It was always appropriately stressed that force and mass are different, that mass can be measured in kg, and that force can be measured in N or lb. It was sometimes mentioned that there was an imperial mass unit called a slug, but it was rarely used anymore.

It's just my opinion, but it seems at some point someone moved toward validating the confusion between force and mass by making both lb_f and lb_m be valid units (in their context). You mentioned 9.81, which is the metric value of gravitational acceleration on earth. And that's where I would have assumed aerospace engineers go to do their calculations: to a place where "lb" is not even a recognized unit. But I'm not an aerospace engineer. Since 'lbm' is not currently defined by the parser, so we could easily make 'lbm' come into existence and be for mass.

Let's get some consensus on what conventions to apply to the unit parser, and I can submit a pull request to change things. One thing we cannot do: have "lb" sometimes mean a unit of mass and other times mean a unit of force. The way the units module works, it will have to be one or the other.

If any changes happen, there needs to be a careful survey of OPL problems and how they would be affected. grepping for '[\s\"\q\d}][lL][bB][^f]' (looking for lb with no f) finds 869 files in the OPL. grepping for '[\s\"\q\d}][lL][bB][fF]' (looking for lbf) finds only 14. So changing the meaning of 'lbf' would not be so bad. But I think 'lb' has to continue as a force unit.


In reply to Alex Jordan

Re: num_cmp problem with lb, lbf when answer is in N, kN..

by Alex Jordan -
Summarizing, I propose:
  1. make "lbm" a recognized unit of mass with the appropriate conversion factor from "kg".
  2. change "lbf" to be a unit of force instead of its current implementation as "foot pound". This will require surveying the OPL for problems to reword/recode. And there are places like answerFormatHelp.pl where "lbf" is explicitly stated to mean "foot pound", possibly just because that is how it was written in Units.pm in the first place. And still there will probably be local problems on some server somewhere that expect "lbf" to mean "ft lb", so there may be complaints some day.
  3. leaving "lb" to mean a unit of force. I respect the engineering standard that it is a unit of mass, but when you consider the competing convention that it is a unit of weight/force, plus the legacy of its usage that way in hundreds of WeBWorK problems, I lean toward recommending to leave it be.

From the forum community, looking for:

  1. any objection to "lbm"
  2. any objection to the "lbf" change or other consideration regarding a change
  3. further discussion of what dimensions "lb" should have

Implementation:

  • I can easily do 1 (and 3) from the first list.
  • For 2, I don't think I have availability to tackle all that for a while. Ever, would you or anyone else reading this be up to making those changes and opening a pull request?
In reply to Alex Jordan

Re: num_cmp problem with lb, lbf when answer is in N, kN..

by Ever Barbero -
I found another problem with the units. In the USA, most notably in civil engineering, it is very common to use Kpsi and Mpsi as multiples of psi (similarly to KPa and MPa in SI units). So, I would suggest these are added to WebWork. 

Regarding "lbf", I found another source in Wikipedia that supports the use of lbf for force and lb for mass, 
https://en.wikipedia.org/wiki/Foot%E2%80%93pound%E2%80%93second_system#Pound-force_as_force_unit

Changing lbf to be a unit of force requires another unit for energy because currently WebWork has lbf as a unit of energy. Actually energy is ft-lbf. We can find many references to ft.lbf but using a `raised dot' that can be confused with dot product, so I suggest energy be changed to ft-lbf (foot-pound). 

Thank you.
 

In reply to Ever Barbero

Re: num_cmp problem with lb, lbf when answer is in N, kN..

by Alex Jordan -
If "lb" and "ft" are defined, then all of the following are automatically interpreted correctly: "ft lb", "ft*lb", "ftlb", "lb ft", "lb*ft", "lbft", and more. So the energy unit is already available, albeit without hyphens. [Perhaps it would not be difficult to make "-" equivalent to "*" within the unit parsing, but I haven't examined this.]

"psi" is special, because while it is a derived unit based on "lb" and "in", it has its own abbreviation. So "lb/in^2" is automatically available once "lb" and "in" are available. At some point, "psi" was added as its own unit equivalent to one "lb/in^2". (I suspect it was added late, because it is missing from Units.pm's comment section on force units.)

The parser does not detect prefixes like "K" for kilo automatically. Something like "Kpsi" needs to be directly added to the list. We can do that with "Kpsi" and "Mpsi". I'll do these things in time for the 2.13 release. It does beg the question of what about "kpsi", since "k" is common for "kilo".

It doesn't really matter what we would decide on as the one true "correct" meaning of "lb" because there are thousands of existing WeBWorK problems where "lb" already means a unit of weight/force. These problems may use "lb" in the (instructions|background|hint|solution) for the problem, not just in the answer checking. So we could never change the meaning of "lb" in the units parser without comprehensively reviewing and editing all those existing problems. (And even if we did that, it would upset a lot of people who use those problems, have used them for years, and are happy with "lb" being a weight/force unit.)

So will it be enough to have "lbf" and "lbm" mean what you would like them to mean with the next release, and leave "lb" as a force unit? (And from that, "ft lbf" and friends would automatically be available as an energy and torque unit.)
In reply to Alex Jordan

Re: num_cmp problem with lb, lbf when answer is in N, kN..

by Ever Barbero -
1. No objection to "lbm" as a unit of mass. 

2. Enthusiastically agree with "lbf" as unit of force, and even happier if "lbf in" and "lbf ft" are automatically interpreted as torque and/or energy :) 

3. As per "lb", I did a little experiment (see PG code below) and I conclude it is implemented as unit of force, not mass... Please bear in mind that I am a newby, so I may be making a mistake using num_cmp or something. 
    If we have "lbf" implemented (with "lbf in" and "lbf ft" being torque and energy), and "lbm" implemented for mass, personally I have no problem with "lb" remaining a unit of force. 

4. A bonus would be to have "Kpsi", "kpsi", "Mpsi", and "mpsi". Both caps "K,M," and l.c. "k,m," are used in many sources in Engineering. BTW Civil Engineering and (paradoxically) Aerospace Engineering are, to my knowledge, the last bastions of the "customary system". 

DOCUMENT();
loadMacros("PGstandard.pl",);
TEXT(beginproblem());
$F = 10; #lb (mass? force?)

BEGIN_TEXT
$PAR Enter \(F=10\) lb force (or is it 10 lb mass?). $BR
Note: if you respond 44.5 N, WB returns "correct". $BR
If you respond 4536 g, 4536 gr, 4.536 kg, or 4.536 Kg, it says "The units for your answer are not correct". So I conclude that "lb" in the num_cmp means force. $BR

$BBOLD$BITALIC Your answers: $EBOLD$EITALIC$BR
\(F \) = \{ans_rule(10)\} $BR
END_TEXT

$showPartialCorrectAnswers = 1;
ANS(num_cmp($F, relTol => 2, units=>"lb",));

# Show answers after the answer date
SOLUTION(EV3(<<'END_SOLUTION'));
$PAR SOLUTION $PAR
\[ F = $F \;lb \]
END_SOLUTION
ENDDOCUMENT(); 
In reply to Ever Barbero

Re: num_cmp problem with lb, lbf when answer is in N, kN..

by Alex Jordan -
OK, I can make a pull request with all this in time for the 2.13 release. If you want something sooner, I can talk with you about making local modifications to your WeBWorK server. (But if you are using someone else's sever, or the MAA hosting service, it won't be an option.)

Is the "m" in "mpsi" ever interpreted as "milli"?

At https://github.com/openwebwork/pg/blob/master/lib/Units.pm, you can see how units are defined. "lb" is:

'lb' => {
'factor' => 4.4482216152605,
'm' => 1,
'kg' => 1,
's' => -2
},

So it's 4.4482216152605 m kg / s^2. In fact, if the answer is "1 lb" (aka "1 lbf"), you can enter "4.448 m kg /s^2" and it will be marked correct.