Add a vector tool to the graph tool.

[drgrice1]

This was requested by @somiaj in our last developer meeting after I told him that I already had this encoded. I have had it as a custom tool for a long time now.

The usage of the new tool is documented in the parserGraphTool.pl macro.

Here is a problem to test this: Vector.pg.txt

The "vector" graph object derives from the "line" graph object, and the "VectorTool" tool derives from the "LineTool" tool. That saves some code redundancy.

The fill tool is perhaps a bit odd with a vector because I am not sure exactly how that should work. Initially I made it so that fills just ignore vectors. But I decided to go with making fills work the same for vectors as for lines even though vectors don't extend to infinity. This allows for vectors being put together to create a bounded region and in that case a fill works naturally.

Note this tool could be copied and a few lines of code changed to make a line segment tool.

Edit: I have now added a segment tool and graph object and a non positional vector grading option.

The segment tool and vector tool both derive from the line tool and share much of the same code. The segment graph object and vector graph object derive from the line graph object and also share much of the same code.

The vectorsArePositional option controls how vectors are graded. This is 0 by default which means that if a vector is graphed that has the same magnitude and direction as the correct answer, then it is considered correct. If the option is set to one, then a vector must also have the same initial point as the correct answer to be considered correct.

Note that if the vectorsArePositional option is 0 and a student graphs the same vector twice at different locations, then the second vector will not be considered correct. That is unless there are two correct answers that are also the same vector.

However, if the student graphs the same vector twice at the same location (so visibly only one is seen), then the second vector is ignored, and the answer will still be correct. This follows the usual rule of the default grader in attempting to grade things according to what is seen.

Both tools are still rather odd with respect to fills.

[pstaabp]

Looks good.

[Alex-Jordan]

This has those conflicts now that you mentioned.

[drgrice1]

The conflicts are resolved.

[Alex-Jordan]

I'm uneasy about publishing this as the official "vector" tool. It's more like a directed line segment. For example it won't consider {vector,solid,(0,0),(1,1)} and {vector,solid,(1,1),(2,2)} to be equal even though they are equal as vectors. I'm thinking about exercises where I am trying to teach students that it doesn't matter where you draw the vector, only its direction and magnitude. Of course, the default cmp for this could be overwritten to get a true vector comparison. But then I started thinking why not have that kind of true vector cmp in the distribution?

Note this tool could be copied and a few lines of code changed to make a line segment tool.

How would you feel about changing this to a "line segment" tool with the option to have the segments be directed? (Similar to the option to have them be solid or dashed?) And then we could reserving a true "vector" tool for the future?

[drgrice1]

Initially I was going to respond that I am okay with that, but in thinking about it further I am not. Your point is not about how the tool works, but how the graphed object is graded. Graphically speaking a vector is a directed line segment. Different graphical representations are not equal, even though as a vector they might be. So it seems to me that you would like options for how the grader behaves. The current grader distinguishes between different representations of the same vector which might be desirable for certain problems. While other problems may not care about the location of the vector.

I am not okay with having a "directed line segment" object and a "vector" object where the only difference is really how they resulting graphed object is graded.

In fact, now that you bring this up, I think that there should never be a "vector" graph object. The tool should be a segment tool. The graph object syntax should be changed to {segment,solid,directed,(0,0),(3,4)} or {segment,solid,undirected,(0,0),(3,4)} similar to the horizontal and vertical parabola syntax. Of course then two actual tools are needed. An undirected line segment tool and a directed segment tool. One that produces an undirected line segment and one that produces a directed line segment. Code wise the two would be derived from a single tool the same as the VerticalParabolaTool and HorizontalParabolaTool in relation to the ParabolaTool (which is never invoked directly). An undirected segment would be graded simply based on having graphed the correct enpoints in either order. For the directed segment, the grader would have options that the author could select as to whether position is considered or not.

Although I don't think undirected is a good choice there, so what would be? For the most part this is just authoring terminology of course, although students do see this in the "Entered" feedback (assuming that you show that for your course).

[Alex-Jordan]

Maybe "arrow" tool?

If I ever did want to make a true "vector" tool, I was thinking of one that would be much like this "arrow" tool. But when focus is on the arrow, a vector field of parallel arrows becomes visible. So it would be something a bit more different than just the checker. But what you've outlined would be good.

If this is really how things will go, then I can be fine with "vector" for the name of the "directed segment" or "arrow" tool. I just did not want to use up that label if there were the possibility of something more truly vector-like arising in the future.

[drgrice1]

I don't understand what you mean by an "arrow" tool versus a "vector" tool. What do you mean that when focus is on the arrow a vector field of parallel arrows becomes visible? To me that does not sound like a good idea even when it comes to thinking of vectors.

[Alex-Jordan]

I will explain but also we can move on, as I am not suggesting doing this.

By the vector <1,1>, I mean a mathematical object. It has infinitely many visual representations as an arrow, but a user can only create/interact with one of them. The user could draw one representation, say the arrow from (0,0) to (1,1). And when focus is not on that arrow, that is all you see. When focus is on that arrow, we remind the user that this one arrow is too specific and that location does not matter. We do this by showing lots of other representations of <1,1>. Not all of them of course, as that would flood the screen. But enough to show that vector as a constant vector field. The user would see a vector field with <1,1> plotted at other helpful places, appropriately spaced apart. The one arrow the user can interact with would remain its usual heavy weight, and the other arrows would be faint.

[Alex-Jordan]

I was wondering based on the thread if you plan to change this to a "segment" tool. Or rather, two segment tools (directed and undirected). I'm wondering because of #1201 and the comment that there is a "vector" tool problem in there.

[drgrice1]

I am going to change this in some way, but haven't entirely decided on how yet. I don't entirely like the "directed" and "undirected" segment though. I am sort of thinking of just a "segment" and a "vector" with options for grading vector taking position into account or not.

[Alex-Jordan]

That sounds good.

[drgrice1]

Attached is a problem for basic testing of both tools.
SegmentAndVector.pg.txt

[Alex-Jordan]

These work nicely, and will be nice to have the next time I have a linear algebra section.

[somiaj]

Thanks for taking the time to allow vectors to be graded independent of location.