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
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.
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.
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
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
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.
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:
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.
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.
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
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.
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.
MathQuill doesn't actually add unnecessary parentheses. It adds the parentheses that are needed to equate the displayed format to the format that MathObjects needs to be interpreted in the same way that they are displayed. With the next release of WeBWorK and PG there are some changes to this. MathQuill will not add as many parentheses, but PG will also parse the answers differently so that things work better.