-
-
Notifications
You must be signed in to change notification settings - Fork 76
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
basis_checker_columns() from pg/macros/MatrixCheckers.pl is not as dependable as would be desired #409
Comments
Hi! Paul Pearson here. I'm glad someone is looking into these issues, as they were known issues when I hurriedly wrote the MatrixCheckers.pl macro and the solution I chose was suboptimal. I found that moderate tolerances seemed to work well enough, but evidently I didn't test that thoroughly enough because you've identified issues with the tolerances. I don't have time right now to work on this. I encourage you to work with Nandor, Davide, and others to fix the issues and merge them into the codebase. Thank you for all of your help with this. |
@paultpearson - Thanks for the comment about the history, etc. The issue certainly relates to tolerance issues, and since it seems to be more likely to accept incorrect answers (of a hopefully relatively unusual structure) than to reject incorrect ones, I suspect that few students are likely to have noticed or complained. Further testing with the test problem from the prior message triggers the problem for the answers: (0,1,-1,-1) and (01,1,-1,-1+0.002), so the problem does not really depend on using an ugly multiple of the first basis vector. (I discovered the issue when testing how code was handling such uglier answers.) After some additional thought on the issue, I think that the root cause of the bug is how the current code checks that the student's vectors are in the space. The existing code:
calculates a "change of basis matrix The proposed code uses "fuzzy" rank calculations with a smaller tolerance to test (in advance) whether each of the student's vectors are in the given space. So far as I can tell, it is far more accurate it detecting vectors which do not belong to the given space. However, the proposed fuzzy rank code was not sufficiently accurate in detecting linear dependence among the student vectors is some cases, so the proposed code relies on the determinant based test from the existing code as a fall back measure. The fall back code does not seem to be triggered very frequently, but it did catch some things which the rank based code did not. I'm not certain that the fallback code really has much of a practical effect, but I recall one test where without it the number of independent vectors belong to the space was reported incorrectly, as the shift was small enough for the shifted vector to be considered to be in the space while large enough for it to be considered independent of the unshifted vector. This issue led to my decision not to report linear dependence of the submitted answers when some vector in the answer was detected not to be in the space. Below is a second test problem for a basis of size 3, where the same sort of problem occurs - if the last vector in the answer is shifted a bit (not too much, not too little) from the sum of the first 2 (correct) basis vectors, the incorrect answer will be accepted.
|
I do hope that I will be able to recruit someone to help test the new code in addition to me before we embark on changing the code in the main It should be pretty to use On the other hand, not rolling out a fix does leave the problematic code pretty widely used in a number of OPL linear algebra problems, which I think is not an ideal situation. @paultpearson - Do you think you might be able to help with looking into this during the summer? @mgage - Can you think of other people who have worked on the linear algebra material who might be willing to help look into this issue and test the proposed code? |
I have been coding some Linear Algebra problems, and started to make use of
basis_checker_columns()
frompg/macros/MatrixCheckers.pl
. I have found that it is not as dependable as would be desired. It also gives minimal feedback and does not give partial credit.In order to overcome these, I found that I had need for a reasonably dependable
rank()
function for MathObject matrices.There is a rudimentary rank.pl at https://github.com/openwebwork/webwork-open-problem-library/blob/master/OpenProblemLibrary/NAU/setLinearAlgebra/rank.pl which seems to work reasonably well for matrices with integer or fractions as the entries. It was not intended to handle uglier numbers well. There is also the `$M->order_LR' function, but as explained by @dpvc in a forum post that misbehaves due to doing exact comparisons to 0 when floating point linear algebra algorithms need to have some tolerance to them. (Matlab's rank function claims to be an approximation to the rank for similar reasons, and takes a tolerance as an optional second argument.)
So I coded a new
rank.pl
based on @dvpc's suggestions, and with additional changes so it can handle non-square matrices. As it used fuzzy comparisons it is not 100% accurate, but seems pretty reasonable in my testing so far.Using the rank() function, I could redesign
basis_checker_columns()
to be more reliable (in my testing).Below are
rank.pl
,CustomBasisChecker1.pl
basis_checker_columns()
and my proposedbasis_checker_columns_tani()
in one file, so they can be easily compared by just changing the value ofchecker
), andbasis_checker_columns()
and some of the limitations of the proposed alternative:test_CustomBasisChecker1.pg
.Some additional testing of the rank function from
rank.pl
would be helpful, as well as a review ofbasis_checker_columns_tani()
. The checker can either replace the oldIf and when the proposed alternative is considered good enough, similar changes can be made to the other checkers in
pg/macros/MatrixCheckers.pl
and provided either as replacements or alternatives to the existing ones.rank.pl
follows:CustomBasisChecker1.pl
follows:test_CustomBasisChecker1.pg
follows:The text was updated successfully, but these errors were encountered: