PG 2.20 Release Candidate #1231
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…tting. In #1157 I made it so that the `up`, `down`, and `drag` handlers for the defining points of graph objects are not added to static graph objects. However, in doing so for intervals I also made it so that the paired point association is not made. For most graph objects those associations are only needed when the handlers are added since they are used to prevent points from being moved in such a way to prevent degeneracy for the object. But for intervals that association is also used to determine which direction the brackets or parentheses should face when the `useBracketEnds` option is used. As such, now correct answer graphs always show those facing to the right even if they are on the right end.
…s-fix Fix bracket ends for graphtool intervals with the `useBracketEnds` setting.
Update permissions.
Update existing problems. This includes * removing the subjects of 'answer' and 'graphs' and reclassifying appropriate places for these problems. * running perltidy again on the sample problems. * adding some additional links (categories, see_also, ..)
Also, add a Line Segment tool, which was also just added.
That is a fill algorithm that fills to borders. The current algorithm is an "inequality" fill. That means that it shades all points that satisfy the same inequalities relative to the graphed objects as the fill point. The previous inequality fill algorithm is still available, but the flood fill algorithm is the default. To use the inequality algorithm set `useFloodFill => 0`. The inequality fill does not entirely make sense with triangles, quadrilaterals, vectors, or segments. The flood fill is more intuitive in general for all available objects. However, the inequality fill will work better for some scenarios. For example, if the problem is to solve a system of inequalities. That is of course what the inequality fill was designed for. However, with the addition of these new graph objects for which there isn't a single inequality that describes the "sides" of the object (like triangles and quadrilaterals) or that don't divide the plane into regions (like vectors and segments) the flood fill is needed. There is one caveat with the flood fill to watch out for. The flood fill considers the edges of the board to be borders. That means that if an object goes off the edges of the board that fills will stop there. For instance, if the board's ranges are -10 to 10 in both directions, and the circle centered at the origin with radius 10 is graphed, then a fill that is placed at the point (8, 8) will only shade the upper right corner of the board outside the circle, and not the upper left, lower left, and lower right corners. This is a case that the inequality fill is better. It will shade all four corners since they all satisfy the inequality x^2 + y^2 > 100 that the point (8, 8) satisifies. So authors will need to consider the options carefully and decide which is best for their problem. If the flood fill is used, in many cases care will need to be taken to ensure that the expected region is filled and that random parameters won't generate something that could cause unexpected results. In addition, if the inequality fill will work, then that should be chosen. It is much more efficient and reliable both for javascript client side, and for hardcopy generation server side. Although, I believe the flood fill should work quite well in most cases now. The TikZ code performs the same flood fill algorithm that the javascript does, and then uses an edge detection algorithm to convert the filled region into an outer curve that is filled and inner curves (if there are holes) that are clipped out. The edge detection seems to be working rather well in the scenarios that I have come up with, but there may be issues that may require that the algorithm be tweaked further. The default grader for fills if the flood fill is used also performs the flood fill. Basically, it starts at the correct fill point and performs the flood fill algorithm until it reaches the student's fill point. As such it can't use MathObject Reals because they are way to slow. MathObject Reals really aren't needed for this anyway though. These are answers provided from the javascript, not things entered by students into a text or MathQuill input. I also noticed that concave quadrilaterals were being filled in the interior an odd way with #1202 and the inequality fill. Only the portion of the interior that satsifies the same inequalities relative to the borders was being filled, and not the entire interior. So this also fixes that issue. Now the entire interior of a quadrilateral is filled unless it is a crossed quadrilateral. Although, as noted above, using the inequality fill with quadrilaterals doesn't make much sense.
This method is passed what is needed and returns if the given point is on the boundary of the object or not. Vectors and segments check to see if they are crossed when moving from one check point to another when trying to determine if a fill check point is a border pixel. This is finally a reliable approach for segments and vectors.
This is a quick hack because I can't figure this out. When certain segments or vectors are graphed that poke into the region or don't bound the region, then the flood fill algorithm starts repeatedly filling already filled pixels in an infinite loop. The break added here stops the loop and the fill completes seemingly correctly. The corresponding Perl algorithm does not have this problem.
This gives a little bit better alignment of the fill image, and is more consistent with the corresponding perl code.
…countered. I haven't seen the need for this unlike the corresponding JavasScript code, but it is probably good to have the protection in place just in case.
This is more efficient and accurate, particularly for horizontal and vertical lines.
Make the flood fill algorithm opt in. This is probably better and is certain to be backward compatibe. Perhaps auto detection could be used and the flood fill algorithm switched to if certain objects are graphed that the flood fill algorithm works better for. However, I am going with this for now.
Update the strings in the pg.pot file.
Add a flood fill algorithm to the GraphTool.
If an infinity is the left operand and a `Fraction` the right operand of an inequality operator, then the operator is returning the wrong thing. This is caused by the change in #1208 failing to account for the op order flag when a fraction is compared to an infinity. For example if `$a = Compute('5 / 3')` (in the `Fraction` context), `$posInf = Compute('-inf')`, and `$negInf = Compute('inf')`, then `$posInf < $a` is true, `$posInf > $a` is false, `$negInf < $a` is false, and `$negInf > $a` is true. All of which are exactly the opposite of the correct result. However, `$a < $posInf` is true, `$a > $posInf` is false, `$a < $negInf` is false, and `$a > $negInf` is true as is expected. The problem is that since the op order flag is not accounted for, the first four comparisons are really returning the result of the latter four comparisons. With this pull request all of the above comparisons are correct.
Fix comparison of a fraction to infinity.
Fix typo in Matrix doc and add a test.
and updated others for consistency.
Include the rest of the Union macros in the deprecate and move the PGnumericevaluators out of deprecate because every problem loads it. In addition show a warning to instructors if a problem is using a deprecated macro.
Save the list of deprecated macros in the PGloadfiles object.
Add plots sample probs
and updated others for consistency.
Deprecate some more macros and set a warning if using.
Include the rest of the Union macros in the deprecate and move the PGnumericevaluators out of deprecate because every problem loads it. In addition show a warning to instructors if a problem is using a deprecated macro.
This method is not used, and definitely never should be. The method was intended to be used in a maketext call with `[tense,_1,present]` or `[tense,_1]`. If `present` is given then 'ing' is appended to the given interpolated value, otherwise 'ed' is appended. However, there is no possible way that will be valid for most languages other than English, and hence this was entirely invalid to use and should not exist. This method is a carry over from the original code here which was copied from the `Locale::Maketext::Simple` package.
Remove the localization `tense` method.
This method is not used, and definitely never should be. The method was intended to be used in a maketext call with `[tense,_1,present]` or `[tense,_1]`. If `present` is given then 'ing' is appended to the given interpolated value, otherwise 'ed' is appended. However, there is no possible way that will be valid for most languages other than English, and hence this was entirely invalid to use and should not exist. This method is a carry over from the original code here which was copied from the `Locale::Maketext::Simple` package.
long image descriptions
Buttons are better for interactive elements than badges. To facilitate making it easier to make general javascript for PG the `details-accordion.js` file is renamed to `generic.js`, and that file is used for the inline javascript in this case. Unfortunately `problem.js` cannot be used due to a conflict with the webwork2 `problem.js` file. Also, the dismiss button inside the details is now in a display flex justify-end div instead of using `float`.
These are only shown in HTML at this point. Also switch to using an indented heredoc for the script in this case (something I have been meaning to do throughout the parserGraphTool.pl code).
This adds the ability to see the long description as a footnote in TeX hardcopy output. It also fixes an issue with PTX output if an array of long descriptions were sent to the image() function.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Re-target pull requests that you want in the release for this branch.