** Using WeBWorK **

I explained to my students that function evaluation takes precedence over exponentiation, so that this is taking the cosine of e, then raising that to the x power. But it seems some of them forget this quickly.

In class I would naturally write the above as $(cos(e))^x$. It would be nice if the Previewer did this too.

Actually, I just ran into the same problem with arctan9x, which appears as $atan(9)x$, whereas the student meant arctan(9x). This error should have been more obvious to my student, but it would have been nice to have $(atan(9))x$ in the Preview.

Thanks. -Dennis

<| Post or View Comments |>

Although this won't help you for these problems, the new parser that I wrote does, in fact, show things like (cos(e))^x with the extra parens. It doesn't add them in your second case, however, but it could be made to.

It is also possible to have the new parser evaluate atan9x as atan(9x), but this does introduce other subtleties that some people will not like. The new parser will handle cose^x as cos(e^x), though that is configurable so it could produce (cos(e))^x just as easily. (I should probably make the default be that, since that's what WeBWorK currently does.)

It turns out that it is a suble issue when to add extra parens and when not to. For more complicated formulas, they can make it become rather overwhelming.

Davide

<| Post or View Comments |>

It gets tricky since normal parentheses can have two interpretations - grouping and normal function notation. So,

  cos x^2  --> cos(x^2)
  cos(x)^2 --> (cos(x))^2

John

<| Post or View Comments |>

Indeed, that is the functionality that the new Parser has (or had until I changed the default for function-apply to mimic the current WeBWorK interpretation).

The new parser's approach is to consider function application to have a precedence, just like addition, multiplcation and all the other operations. Since "cos x " looks like multiplication, I had originally made function apply have the same precedence as multiplication, so "cos x^2" would parse as cos(x^2) since ^ has higher precedence.

Making function apply have precedence slightly lower than multiplication makes "cos 2x" parse as cos(2x). Unforunately, it also makes things like "cos 2xy (x+1)" parse as cos(2xy(x+1)), and also "cos x / (x+1)" parse as "cos(x/(x+1))". I'm not sure these are the most appropriate choices. The first might be better as "(cos 2xy) (x+1)" and the second as (cos x)/(x+1).

My solution was to make the spacing count (by making two kinds of implied multiplication, direct juxtaposition and juxtaposition with a space, each with a separate precedence). By making the precedence of justaposition higher than function apply which is higher than space-justaposition, we can make "cos 2xy (x+1)" be "(cos(2xy))(x+1)". Similarly, we can make a difference between / and /-with-spaces to make "cos x/2" become cos(x/2) but "cos x / 2" be "(cos x)/2".

Of course, this makes the statement of the "rules of precedence" considerably more complicated, so students may find it harder to understand. On the other hand, they don't understand the current rules, so how much is lost? Especially if it gets more of the situations to correspond to what they think they mean. And since the parser allows you to set the precedences, you can always pick the style that you want for your class (though this may confuse students when they use WeBWorK in another class).

Note, however, that this doesn't help one other situation that students find hard, namely e^2x meaning (e^2)x rather than e^(2x). Here the standard precedences should make this clear, but apparently doesn't. Note that the real problem with cos 2x is not knowing what the precedence of function apply is.

Anyway, I'm not sure that the non-standard precedences is really a good idea, but they are in the Parser so you can try them out if you like.

Davide

<| Post or View Comments |>

One thing that some professors might want to do is to force their students to use parentheses in function calls. For example, sin x would yield a syntax error with a message such as "missing left parentheses". Does your parser have this capability? Of course even this gets a bit complicated since some prof's may want only parentheses and others would allow braces and/or square brackets.

Other than possibly requiring parentheses in function calls, my own personal preferences would be to stick with what WeBWorK currently does. At least there are understandable rules. A long time ago I looked through calculus books and saw the same examples that John mentions, e.g. sin 2x but, if I recall correctly, I never saw anything more complicated, e.g. sin 2xy was always written as sin(2xy).

The fact that your parser has the flexibilty to set things the way a prof wants is great. On the other hand, probably 95% of prof's will use the defaults, so we should be careful choosing those so that they satisfy most people.

One more question. Are the defaults for the parser setable in global.conf?

Arnie

<| Post or View Comments |>

A quick glance through a multivariable calculus text (Williamson and Trotter) revealed

          sin 1/t
          sin t^2
          cos xy
          atan y/x

in addition to the very common

          sin 2x

case, so they are not altogether unknown.

I'm not absolutely convinced that the proposal I outlined above is the right way to go; it is an experiment that I think has promise. One of the nice things about it is that it is stated purely in terms of precedence rules, with no special cases, though admittedly there are more operators than usual. But the CONCEPT is not more complicated than normal rules of precedence. Viewing function application as a form of multiplcation has its appeal as well.

The default settings for the parser are to duplicate the current WeBWorK parsing. I provide the alternate precedences as an experiment to see what works and what doesn't. It may well be that the rules are viewed as too complicated.

As a side note, there are several other issues that confuse students that the new parser may help. For example, it can handle sin^2 x as (sin x)^2 and sin^(-1)(x) as arcsin(x). It also has absolute values as |x| and factorials as n!. Plus there's the vector, matrix, complex, interval, union, list and other classes of results in addition to numeric ones.

In terms of configuring through global.conf, certain of the defaults can be controlled directly within global.conf, but not all of them (at the moment). The parser is controlled by a Context object that contains all the information about the operators and functions that are allowed, and so on. There are a variety of predefined contexts (for vectors, complex numbers, etc), and a problem writer can load additional ones or even create his own or copy and modify an existing one. But because the predefined contexts are created in the .pm files that are loaded into the persistent mod_perl process, they do not have access to the course's course.conf data, so this makes setting the values via course.conf somewhat tricky. I'll think about how to handle it best.

Davide

<| Post or View Comments |>

I don't really like the use of white space to distinguish situations as described a couple of posts up. While it may guess right more often, it has the disadvantage of seeming too non-standard. The best reply I have for students who complain about webwork syntax is that it is standard. Having this as an option is good, but it probably shouldn't be the default.

In the discussion above, I haven't seen an argument against having precedence rules for functions be

1. if the function name is immediately followed by an open paren, then the expression in the parentheses is the argument to the function
2. otherwise, binding a function to its argument is strictly between addition/subtraction and multiplication/division in the order of operations

John

<| Post or View Comments |>

      cos2x (x+1)

parse as cos(2x(x+1)) which I don't think is likely to be what is intended.

As I mentioned, I'm not yet convinced that the "space" idea is the right one. But it has worked well in the situations where I've tested it. I'm not really sure how to interpret what "standard" is because I don't know of many languages that allow you to do function application without parentheses of some kind (in a natural mathematical setting). WeBWorK's approach is certainly straight-forward, but I submit that it does not correspond well to the usage in mathematics. It may well turn out that "mathematical usage" is contradictory or not easily codified, but I think it is worth a try.

As to whether it is reasonable to use spacing to make a distinction, I don't see why this shouldn't be considered. Spacing is important in many computer situations, so asking students to pay attention to that may be valuable training. I'm not sure why it's more acceptable to ask them to pay attention to precedence rules but not spacing.

In terms of the spacing itself, it seems to me that

       cos 2xy           and           cos 2x y

give very different visual impressions, and I don't see why that difference in visual sense can't be mirrored in a mathematical difference.

One reason that computer languages have used the simpler precedence rules in the past is that more sophisticated approaches require more computational power. As our computers become faster, we can begin to consider more complex, and perhaps more natural, interpretations of mathematical expressions.

Davide

<| Post or View Comments |>

Larry Wall is actually doing this in some cases in Perl 6. For example:

The parser will make use of whitespace at this point to decide some things. For instance

 

    $obj.method + 1

 

is obviously a method with no arguments, while

 

    $obj.method +1

 

is obviously a method with an argument. However, the dwimmery only goes as far as the typical person's visual intuition. Any construct too ambiguous is simply rejected. So

 

    $obj.method+1

 

produces a parse error.

<| Post or View Comments |>

People get their feathers ruffled when the system doesn't act as they expect. The best defense of the system is when it is following an existing standard. What we have here seems to be a somewhat grey area, but as a starting point I discount complaints which go against the standard (which is the majority of them). Among the various suggestions, I think the webwork audience would be least surprised by what I suggested above.

John

<| Post or View Comments |>