## WeBWorK Problems

### Entering Trig functions in WeBWorK not mathematically consistent

by Paul Seeburger -
Number of replies: 13

When I enter  sin x7  in WeBWorK (or  sin x^7), it interprets it as  [sin(x)]^7.

Why is this?  That's the same mistake my students sometimes make for these functions when we write them out on paper.

WeBWorK does correctly understand  sin7 x  (or  sin^7 x) as [sin(x)]^7.

Why not the other one?

Thanks!

Paul

### Re: Entering Trig functions in WeBWorK not mathematically consistent

by Alex Jordan -

I'm not weighing in on what it should do, but the explanation for what you see is probably that function application has higher precedence than exponentiation. "sin x^7" is the same as "sin(x)^7" and with the latter, I'm guessing that you would want that to mean "[sin(x)]^7".

Distinguishing when the function is grabbing its argument with explicit parentheses, versus when the argument is the most immediate operand according to precedence, versus when the argument is some expression that by convention is grouped prior to function application precedence is a challenging issue. IIRC, Davide Cervone had some experimental work to make things like "sin 2x" be read as "sin(2x)" but it ran into some obstacles that were too much. And this seems to be a similar thing.

### Re: Entering Trig functions in WeBWorK not mathematically consistent

by Glenn Rice -

I have noticed this as well.  The same thing happens for the natural log.  As such, I always make sure to add parentheses when I am using these functions in class.  That of course is just my workaround.  I agree that this should be fixed.

### Re: Entering Trig functions in WeBWorK not mathematically consistent

by Arnold Pizer -

I'll take a shot at this.  This is how WeBWorK has worked since day 1.  Look at Set 0 which is an intro to WeBwork used at Rochester in 1996 or maybe a year or two later. Or Davice Cervone's Orientation set from probably the early 90's. His Problem 8 states

## Rules of Precedence (Again)

At this point, we can give the complete rules of precedence for how WeBWorK computes the value of a mathematical formula. The operations are handled in the following order:

1. Evaluate expressions within parentheses.
2. Evaluate functions such as sin(x)cos(x)log(x)sqrt(x).
3. Perform exponentiation (from right to left).
4. Perform multiplication and division, (from left to right).
5. Perform addition and subtraction, (from left to right).

This can get a little subtle, so be careful. The following are some typical traps for WeBWorK users. ....

The point is it is very difficult to decide how to interpret things like sin 2x if you want that to be sin(2x). E.g. what does sin 2xsin(y) mean or sin 2x+3y^2 or sin 2xsin 2y+3y^2.  If you look at text books you will see sin 2x but usually nothing more complicated.  But students can enter things that are much more complicated.  I think it is a lot better to have simple understandable rules of precedence rather than rules with special cases.

Arnie

### Re: Entering Trig functions in WeBWorK not mathematically consistent

by Davide Cervone -

Both Alex and Arnie are correct on this. This is how the rules of precedence work, and how they have been implemented from the beginning of WeBWorK before there were MathObjects. A function applies to the next complete term in the expression, and so sin 3x is sin(3) x and sin x^2 is (sin x)^2 while sin (x^2) is sin(x^2) as expected, since the next term in this case is the parenthetic one. On unusual case is  sin -x^2 which is sin(-(x^2)) since the next term is -x^2 is the next term based on the precedences of negation and exponentiation.

One could set the precedence of exponentiation to be above that of function application, but then you run into other problems, like that x^sin x now means (x^sin) * x, which is unfortunate, so you must do x^(sin x). And then would you expect sin 2x to mean sin(2x)? Arnie pointed out a number of other situations where there is ambiguity.

Alex points out that I had tried to make a set of precedences that would allow sin xy to be sin(xy) but sin x y to be sin(x)*y by allowing spaces to be used to make different operators that could have different precedences, but it ended up that the situations became too complicated, and the rules were not obvious. There are still remnants of this in the parser, as there are separate operators for '*', ' *' and '* ' that could have different precedences. In fact the precedences defined in the Parser/Context/Default.pm file are the non-standard ones that I tried to get to work. These are changed later by a call to another function (defined here) that sets them to the standard ones. I think the extra operators and the non-standard precedences should probably be removed, but there are some contexts that change the properties of these operators, so it would take more than just editing the default file.

As Arnie points out, for students, you need rules that are clear and uncomplicated. That's what the current precedences do, and that is probably why they were set that way originally. MathObjects simply mirrored the decisions that had already been made earlier. So from my point of view, there is nothing to be "fixed", as they are already doing what they were intended to. If someone wants to propose another set of precedences, that would certainly be something that could and should be debated. But the implications of such changes can be subtle.

### Re: Entering Trig functions in WeBWorK not mathematically consistent

by Paul Seeburger -
Thank you all for your replies!

As I see it, MathQuill now makes these expressions look so much like what we see in textbooks (or on our chalkboards) and which are unambiguous in that context (though perhaps not always for our students) that it makes it seem more unusual that they were not understood to mean the same thing by WeBWorK. It's unfortunate that MathQuill can't add the needed parentheses, as it seems to add parentheses in many places they are not needed in other situations. And it also seems to recognize sine and cosine functions and to render them so nicely with proper spacing that it's easy to assume they were understood correctly as they were entered.

It's also unfortunate that my students sometimes already have the misconception that sin x^7 does mean (sin x)^7, and now I am seeing that WeBWorK reinforces this misconception instead of helping to overcome it. =( Oh well.

I think that if WeBWorK did not allow trig functions or logarithms, etc., to be entered without parentheses around their arguments, it would be less of an issue. But I expect there is probably a reason that adding this restriction would cause even greater problems, so it's probably best to just keep telling students that they really should always use parentheses around arguments of the transcendental functions to be safe... and to watch the Answer Preview to see if their answers were interpreted as they intended.

Thanks again!

Paul

### Re: Entering Trig functions in WeBWorK not mathematically consistent

by Paul Vojta -

Some time ago I looked into this issue carefully.  Basically, I tried to figure out some rules that provide a decent approximation to how we interpret formulas on a printed page.

Unfortunately, I can't find my notes on it, but my recollection is the following:

The argument of a named function (sin, cos, log, etc.) is determined as follows:

1.  If the first token after the function name is a left delimiter (e.g., left parenthesis, bracket, | (absolute value function), or \langle (bilinear pairing)), then the argument includes up to the matching right delimiter and exponent (if any) but goes no further.

Examples:

• sin(x)y --> (sin x) y
• sin(x+y)^2y --> (sin((x+y)^2)) y
2.  If the first token is another named function, then the argument is the value of the second function (with its argument, as determined recursively by these rules).You can see that these rules seem to be consistent with what WolframAlpha does (although I haven't tested all cases).
• log log log x --> log(log(log x))
• log sin(x)y --> (log(sin x)) y
• log sin(x+y)^2y --> (log(sin((x+y)^2))) y
• log log (x+y)z --> (log(log(x+y))) z
3.  Otherwise, the argument is the monomial that comes next, except that it stops just before any left delimiter or named function.
• sin x cos y --> (sin x)(cos y)
• sin x|y| --> (sin x)|y|
• sin x(y+z) --> (sin x)(y+z)
• sin 2x^2y^3+7 --> (sin(2x^2y^3)) + 7
You can see that these rules seem to be consistent with what WolframAlpha does (although I haven't tested all cases).
I doubt that these rules can be implemented within a framework of precedences, though.
Paul Vojta

### Re: Entering Trig functions in WeBWorK not mathematically consistent

by Davide Cervone -

Thanks for the description of a complete set of rules that does a pretty good job of doing what you intended.

A couple of observations:

• The MathObject parser already does your first two points, other than include the exponent. So sin |x| is sin(|x|), log sin x is log(sin(x)), and log log (x+y)z is [log(log(x+y))]*z. I am concerned about including the exponent clause in your rule, however. It seems to me that if a function is followed by an open parenthesis, then its argument should end at the close parenthesis, period. As an aside, this is not consistent with WolframAlpha, which interprets sin(x+y)^2y as [sin(x+y)]^2 * y, just as MathObjects does, and similarly for the third example in part 2.

• The monomial idea is an interesting one, but it is not clear to me exactly what constitutes a monomial. For example, is sin 2/3x to be sin((2/3)x) or is it ([sin(2)]/3) * x? WolfraphAlpha does treat this as the first. Now how about sin (2/3)x; should this mean the same thing? WolphramAlpah treats is as MathObjects would: [sin(2/3)] * x. What about sin 2x/3? Or sin 2x/3y, which I can see students writing when they mean sin((2x)/(3y))? How about sin 2(x^2) or sin 2(xy)^2? I would expect sin pi x to be sin(pi*x), but then shouldn't sin sqrt(2)x also be sin(sqrt(2)*x) rather than sin(sqrt(2))*x as the second rule would imply? This all really comes down to what is the definition of a monomial?

• Once you start doing things like sin 2x means sin(2x), then shouldn't you also make x^2x mean x^(2x) rather than (x^2)*x? And shouldn't x/2y more naturally mean x/(2y) rather than (x/2)*y? I have seen this last issue even in hand-written work, not just in typing answers in WeBWorK, as I'm sure many others have as well. Trying to get the linear format used in typing to match the two-dimensional format of printed math in a natural way is difficult and always involves fairly complex heuristics that are hard to define in practice, and hard to explain to students if you do. This is a rabbit hole that, in my experience, will just make it harder for students to understand what is going on (and makes the rules seem "magic" rather than deterministic). The current precedence-based rules can at least be described in a straight-forward way, and even though they don't always translate the printed situation exactly, that is still an important advantage.

One other thought to consider is that the parser is designed to allow you to create contexts other than simple algebraic expressions (e.g., permutations, chemical formulas, and so on). Every operator, function, delimiter, variable, and so on can be modified, removed, or replaced by one with a different definition to allow the expressions to be interpreted differently. The fact that the underlying parsing is simply precedence based, without any topic-specific knowledge, makes it very flexible in a way that might not be possible if the parsing were based on ideas like "monomials" that make assumptions about the meaning of the parsed objects. It might be possible to encode this knowledge into the definitions of the objects, but I haven't tried.

The parser has done a pretty good job for the past 18 years, but I'm certainly aware that there are some design flaws and limitations that I would handle differently now where I writing MathObjects today (indeed, I've written several related parsers since then that resolve some of those problems). I'd love to do MathObjects2 that fixes some of them (and PGML2 that fixes some if its problems), but I don't see having several months free to do that. Sigh.

### Re: Entering Trig functions in WeBWorK not mathematically consistent

by Glenn Rice -

There are certainly big challenges to changing things.  I think it might be best to leave the precedence rules as they are.  At least for now.

Perhaps after researching things carefully and determining the best order some changes could be made.  Very carefully.

I certainly don't thing 1/2x should be interpreted as 1/(2x).  That would break the standard rules for the order of operations with left to right multiplication and division.

### Re: Entering Trig functions in WeBWorK not mathematically consistent

by Paul Seeburger -

I agree with Glenn that we would not want 1/2x to be interpreted as 1/(2x).

But if MathQuill rendered 1/2x to have 1 in the numerator and 2x in the denominator, we would need to interpret it as 1/(2x).  And in fact, this is exactly how MathQuill interprets it when I type in 1/2x. It adds the parentheses.  However the student is not confused, since what they are shown is unambiguous.  If they intended to enter 1/2 x, they will see that they need to move to the right of the fraction to enter the x.

So if  sin x^7 is interpreted as [sin x]^7, why not just have MathQuill render it this way?  Perhaps this would require passing the textstring to WeBWorK and back to MathQuill?  This is probably also not a very easy thing to implement.  But perhaps it's not as difficult as retooling the precedence rules.

That would remove the ambiguity.  And students would see that they need to use parentheses to avoid this interpretation in WeBWorK.

Thanks for all the thoughtful consideration on this topic.  I can see that much thought has gone into the current precedence rules and they are not without merit.  It's really when we introduce MathQuill's rendering (displaying an implicit interpretation) that I feel they become more of an issue, from my current perspective at least.

Thanks so much!

Paul

### Re: Entering Trig functions in WeBWorK not mathematically consistent

by Glenn Rice -

Perhaps this would require passing the textstring to WeBWorK and back to MathQuill?

Not only difficult.  Impossible.  MathQuill is client side javascript.  WeBWorK and PG are server side perl.  MathQuill generates a string to submit, and submits it.  There is no WeBWorK or PG where MathQuill lives.

### Re: Entering Trig functions in WeBWorK not mathematically consistent

by Alex Jordan -
I'll add to the catalog of issues, an issue that I do not think have been explicitly mentioned yet. Just using WA's heuristics for comparison,

"sin 2x + sin2x + sin 2*x + sin2 x + sin 2 x + sin2*x"

has the first three come out as "sin(2x)" and the last three as "(sin 2)*x"
https://www.wolframalpha.com/input?i=sin+2x+%2B+sin2x+%2B+sin+2*x+%2B+sin2+x+%2B+sin+2+x+%2B+sin2*x

So I think something that hasn't been mentioned is the interplay between *two* types of function application (immediate adjacency and space characters) with *three* types of multiplication (immediate adjacency, space characters, and an explicit multiplication). This complicates further what should be considered a "monomial". Especially if you want to preserve WA's heurisitc that "sin 2*x ≠ sin2*x".

### Re: Entering Trig functions in WeBWorK not mathematically consistent

by Danny Glin -

I don't think it's a good idea to use Wolfram Alpha as a basis for these decisions.  WA claims to be a natural language interpreter, so it makes significant effort to determine "what you meant" rather than what you typed.  For example, it interprets x2 as x2.