** Using WeBWorK **

In class and in our book, we will be writing these vectors as (4,5,6) using parentheses. We are going to try to make it clear to our students that they need to enter a vector using < , > instead of (,). Still, I expect to hear some complaints.

Could there be a way to indicate to the Parser.pl that it should count (4,5,6) as the vector <4,5,6>? Perhaps if it is expecting a vector and it sees that (4,5,6) has been entered, it could be programmed to recognize (4,5,6) as a vector instead of a point?

Thanks, Tom

<| Post or View Comments |>

This sort of thing should be managable through the Context. If you were writing the problems now, or were going to modify them, you could could make a new Context which was just like Vector but had the different treatment of parentheses.

I won't try to describe that since it sounds like you have the problems written already and want to change the treatment of parentheses in Vector context. The problems themselves should already have Context('Vector') in them.

To do this, you could modify pg/lib/Parser/Context/Default.pm. That is where vector context is defined. You could add the line

$vectorContext->parens->set('(' => {close => ')', type => 'Vector', formMatrix => 1});

in the area where vectorContext is defined.

John

<| Post or View Comments |>

That change by itself didn't seem to work (The problem still expects a '<'). Does the system need to be restarted for the change to be incorporated into the system?

Thanks, Tom

<| Post or View Comments |>

John

<| Post or View Comments |>

Can this be done on a course by course basis? For example different courses on the same server might be using different textbooks with different notation. Also is it possible to accept e.g. ( or < ?

Arnie

<| Post or View Comments |>

The modification I gave above should already allow

(1,2,3)

<1,2,3>

The quick fix does not easily extend to a course by course customization. I am sure it can be done, but the changes would extend pretty far. If there are several things like this people would want to control, then how configuration should work deserves some thought.

On an individual problem, it is not hard to set it to use () in addition to angle brackets. One could keep parallel versions of problems depending on the tastes of the instructor accordingly. It may seem like lots of work, but we see that sort of thing in other problems where people have different tastes (e.g., should an intercept be entered as a number or a point).

John

<| Post or View Comments |>

There are two issues involved in this discussion: how to make global parser changes on a course-by-course basis, and how to change the way vectors are entered and displayed.

I had been thinking about the first of these for a while, and I think the easiest solution would be to have Parser.pl load another file called, say, parserCustomization.pl after it is finished initializing the parser. This file would normally be empty (or could contain system-wide customization), but professors could put a copy of this in their course templates/macros directory and include other customization. For example, if they wanted vectors to be entered and displayed using ijk notation rather than <,,> notation.

This would require minimal changes (just one line added to Parser.pl and one new empty file), so I'll probably add that to the CVS repository as soon as I get the chance.

These sorts of changes need to be done VERY carefully, however, as they could easily cause trouble for problems that expect the original behavior. For example, ijk notation is only for R³, so it could cause problems that use other dimensions to fail, and there might not be an easy way around that.

As for how to change the context so that (,,) will produce vectors, there are several approaches. If you are writing your own problems, an easy solution is to use the promotePoints option of the Vector object's answer checker, which will cause points to be converted to vectors automatically (this is not true by default). For example,

    ANS(Vector(1,2,3)->cmp(promotePoints=>1));

John's suggestion doesn't require the problem to be written specifically to handle the alternate notation, so is better from that point of view. It has a problem, however, in that there is now no way for the student to enter a point, so ANS(Point(1,2,3)) will not be able to be answered correctly (the student will receive an error message about entering a vector but expecting a point).

To get a round this, there probably needs to be a Point context, just as there is a Vector one. I didn't make one originally since Vector already included the notation for points, but it is probably a good idea to have one so that Vector can be changed while leaving Point unaffected. I will add such a context to the default contexts known to the Parser, but older problems that use Vector context when they are asking for Points will suffer if you change the Vector context to make (,,) produce vectors.

In addition to making (,,) produce vectors, you probably also want to make vectors output as (,,) rather than <,,>, so that students will see the same format that they have to use to enter their answers. There is another portion of the context that should be adjusted for that:

    $context->lists->set(Vector => {open=>"(",close=>")"})

    $context->parens->remove('<');

Davide

<| Post or View Comments |>