Add triangle and quadrilateral tools to the graph tool. #1191
Conversation
drgrice1
force-pushed
the
graphtool-triangle-and-quadrilateral
branch
9 times, most recently
from
f17313d to
d88fb39
Compare
|
The triangle tool worked well. When I used your sample problem with many different seeds (248, 6775), the correct answer wasn't accepted. Those both had internal crossings, so I thought that might be an issue, but I even hardcoded a simple square and didn't work. |
drgrice1
force-pushed
the
graphtool-triangle-and-quadrilateral
branch
from
d88fb39 to
0d76db2
Compare
|
There was a mistake that I fixed recently that made it so the quadrilateral |
drgrice1
force-pushed
the
graphtool-triangle-and-quadrilateral
branch
from
0d76db2 to
922ee87
Compare
This was requested by @somiaj in our last developer meeting. The usage of the new tool is documented in the parserGraphTool.pl macro. The "vector" graph object derives from the "line" graph object, and the "VectorTool" tool derives from the "LineTool" tool. That saves some code redundancy. Note that there will be some minor conflicts with openwebwork#1191 that will need to be resolved.
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. The "vector" graph object derives from the "line" graph object, and the "VectorTool" tool derives from the "LineTool" tool. That saves some code redundancy. Note that there will be some minor conflicts with openwebwork#1191 that will need to be resolved.
These were requested by Robin Cruz in https://webwork.maa.org/moodle/mod/forum/discuss.php?d=8646. The usage of the new tools is documented in the parserGraphTool.pl macro.
drgrice1
force-pushed
the
graphtool-triangle-and-quadrilateral
branch
from
922ee87 to
e0a3d0c
Compare
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. The "vector" graph object derives from the "line" graph object, and the "VectorTool" tool derives from the "LineTool" tool. That saves some code redundancy. Note that there will be some minor conflicts with openwebwork#1191 that will need to be resolved.
|
What should happen if you use the quadrilateral tool to make a "bad" quadrilateral like in the picture, and then fill? The current behavior is to not respect where the edges cross. Just checking that is what we'd want. 
Options:
I am not able to think through which option it should be... |
|
I notice the tool won't let me make a degenerate quadrilateral (like with three collinear points). This is also something I am wondering about. Could there be an exercise where in the abstract you are asking for a quadrilateral (so you provide this tool) but the answer could be a degenerate one? Is the question of allowing degenerate quadrilaterals a separate question from allowing "hourglass" quadrilaterals like in my previous post? |
I realized that is not an option. I had to remember about non-convex quadrilaterals where specifying four points does not uniquely define the quadrilateral. Like three points in an equilateral triangle with a fourth point at their center. |
|
That is how it pretty much how the fill has to work for now. In order to do better it requires rewriting the general graphtool fill code. Currently there is an assumption that objects are two sided. Basically there are three states a point can satisfy. Either the point is on one side of the object, the other side of the object, or on the object. Basically, the Of course quadrilaterals are not two sided. They can have intersection points which result in three regions as in your example. Furthermore, the inequality fill concept doesn't work with this implementation. In order for the inequality approach to work, something more is needed than the current As to degeneracy, I went with the design of the existing tools to not allow degeneracy. For example. the line tool does not allow graphing the same point twice. The triangle tool added here also does not allow three collinear points. Note that the "hourglass" quadrilateral is a valid quadrilateral. It is not degenerate, and so it is allowed. Three consecutive collinear vertices are not allowed in a polygon. In general, a vertex is not allowed to be on the line segment between any two other vertices in a polygon. However, two edges of a polygon are allowed to intersect (just not at a vertex). Note that JSXGraph does allow polygons to be degenerate, and this could be changed to allow degeneracy. The code that prevents degeneracy is in the |
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. The "vector" graph object derives from the "line" graph object, and the "VectorTool" tool derives from the "LineTool" tool. That saves some code redundancy. Note that there will be some minor conflicts with openwebwork#1191 that will need to be resolved.
…point. This is to fix a comment I placed in the code about filling quadrilaterals, and the comment made by @Alex-Jordan in openwebwork#1191 (comment). The code implemented in openwebwork#1191 fills the entire interior of a quadrilateral even if it is a crossed quadrilateral (that is a quadrilateral with two edges that intersect). That is inconsistent with all of the other graph tool objects in some sense. To be more consistent only the region inside the quadrilateral that satisfies the same inequalities relative to the borders should be filled. So that is what this does. I also was doing some benchmarking of the TikZ fill code used for generating hardcopy and noticed that some things were rather slow. The slow down it turns out was using MathObject Reals in computations. There is no need for the MathObject structure in those computations, so all of the fill code now uses the perl values instead. It isn't even funny how much faster computations are with pure perl numbers versus MathObject Reals. The difference is rather extreme. Performing something like 10000 basic arithmetic operations with MathObject Reals takes more than five seconds, but with pure perl numbers it takes less than 20 milliseconds.
…point. This is to fix a comment I placed in the code about filling quadrilaterals, and the comment made by @Alex-Jordan in openwebwork#1191 (comment). The code implemented in openwebwork#1191 fills the entire interior of a quadrilateral even if it is a crossed quadrilateral (that is a quadrilateral with two edges that intersect). That is inconsistent with all of the other graph tool objects in some sense. To be more consistent only the region inside the quadrilateral that satisfies the same inequalities relative to the borders should be filled. So that is what this does. I also was doing some benchmarking of the TikZ fill code used for generating hardcopy and noticed that some things were rather slow. The slow down it turns out was using MathObject Reals in computations. There is no need for the MathObject structure in those computations, so all of the fill code now uses the perl values instead. It isn't even funny how much faster computations are with pure perl numbers versus MathObject Reals. The difference is rather extreme. Performing something like 10000 basic arithmetic operations with MathObject Reals takes more than five seconds, but with pure perl numbers it takes less than 20 milliseconds.
…point. This is to fix a comment I placed in the code about filling quadrilaterals, and the comment made by @Alex-Jordan in openwebwork#1191 (comment). The code implemented in openwebwork#1191 fills the entire interior of a quadrilateral even if it is a crossed quadrilateral (that is a quadrilateral with two edges that intersect). That is inconsistent with all of the other graph tool objects in some sense. To be more consistent only the region inside the quadrilateral that satisfies the same inequalities relative to the borders should be filled. So that is what this does. I also was doing some benchmarking of the TikZ fill code used for generating hardcopy and noticed that some things were rather slow. The slow down it turns out was using MathObject Reals in computations. There is no need for the MathObject structure in those computations, so all of the fill code now uses the perl values instead. It isn't even funny how much faster computations are with pure perl numbers versus MathObject Reals. The difference is rather extreme. Performing something like 10000 basic arithmetic operations with MathObject Reals takes more than five seconds, but with pure perl numbers it takes less than 20 milliseconds.
…point. This is to fix a comment I placed in the code about filling quadrilaterals, and the comment made by @Alex-Jordan in openwebwork#1191 (comment). The code implemented in openwebwork#1191 fills the entire interior of a quadrilateral even if it is a crossed quadrilateral (that is a quadrilateral with two edges that intersect). That is inconsistent with all of the other graph tool objects in some sense. To be more consistent only the region inside the quadrilateral that satisfies the same inequalities relative to the borders should be filled. So that is what this does. I also was doing some benchmarking of the TikZ fill code used for generating hardcopy and noticed that some things were rather slow. The slow down it turns out was using MathObject Reals in computations. There is no need for the MathObject structure in those computations, so all of the fill code now uses the perl values instead. It isn't even funny how much faster computations are with pure perl numbers versus MathObject Reals. The difference is rather extreme. Performing something like 10000 basic arithmetic operations with MathObject Reals takes more than five seconds, but with pure perl numbers it takes less than 20 milliseconds.
…point. This is to fix a comment I placed in the code about filling quadrilaterals, and the comment made by @Alex-Jordan in openwebwork#1191 (comment). The code implemented in openwebwork#1191 fills the entire interior of a quadrilateral even if it is a crossed quadrilateral (that is a quadrilateral with two edges that intersect). That is inconsistent with all of the other graph tool objects in some sense. To be more consistent only the region inside the quadrilateral that satisfies the same inequalities relative to the borders should be filled. So that is what this does. I also was doing some benchmarking of the TikZ fill code used for generating hardcopy and noticed that some things were rather slow. The slow down it turns out was using MathObject Reals in computations. There is no need for the MathObject structure in those computations, so all of the fill code now uses the perl values instead. It isn't even funny how much faster computations are with pure perl numbers versus MathObject Reals. The difference is rather extreme. Performing something like 10000 basic arithmetic operations with MathObject Reals takes more than five seconds, but with pure perl numbers it takes less than 20 milliseconds.
…point. This is to fix a comment I placed in the code about filling quadrilaterals, and the comment made by @Alex-Jordan in openwebwork#1191 (comment). The code implemented in openwebwork#1191 fills the entire interior of a quadrilateral even if it is a crossed quadrilateral (that is a quadrilateral with two edges that intersect). That is inconsistent with all of the other graph tool objects in some sense. To be more consistent only the region inside the quadrilateral that satisfies the same inequalities relative to the borders should be filled. So that is what this does. I also was doing some benchmarking of the TikZ fill code used for generating hardcopy and noticed that some things were rather slow. The slow down it turns out was using MathObject Reals in computations. There is no need for the MathObject structure in those computations, so all of the fill code now uses the perl values instead. It isn't even funny how much faster computations are with pure perl numbers versus MathObject Reals. The difference is rather extreme. Performing something like 10000 basic arithmetic operations with MathObject Reals takes more than five seconds, but with pure perl numbers it takes less than 20 milliseconds.
These were requested by Robin Cruz in https://webwork.maa.org/moodle/mod/forum/discuss.php?d=8646.
The usage of the new tools is documented in the parserGraphTool.pl macro.
Example problems for testing this are attached.
Quadrilateral.pg.txt
Triangle.pg.txt