Fraction eval method should return Real MathObject not perl real #1208
Conversation
macros/contexts/contextFraction.pl
Outdated
| reals. The default is 10E-10, meaning the decimal must match to | ||
| roughly 10 digits. |
There was a problem hiding this comment.
I think you mean 1E-10 here. In the code you use 10**-10 which is equal to 1E-10. Furthermore, that would actually mean roughly 10 digits of accuracy, while 10E-10 only means roughly 9 digits of accuracy.
Not that you don't know that. Probably just a typo, or mental conversion error from the ** notation to the E notation.
There was a problem hiding this comment.
I made a lot minute change from 10**-10, which just didn't look good with the two 10s and negative sign, and didn't change it correctly. I will fix.
There was a problem hiding this comment.
Another minor typo, not from this PR is on line 50 of contextFraction.pl. LimiteFraction. Since you have this open, instead of making another PR.
|
I went to try this out and something strange is happening (even before I check this out).
More out of curiosity that anything else, could this be explained by my perl version? On that develop server the perl version is 5.26, but on my production it's 5.36. |
|
I think there is a POD typo that I still need to fix. Sorry. Will get to that soon. |
|
OOPS, looks like I already did that. Sorry, I thought I hadn't. I think you are good to go. |
|
I noticed your edit to |
|
Indeed, you are correct about the reason. Ok, I can undo the last commit. It is a bit of a pain to remember not to add that file in when making changes, and you can see that I forgot this time. I only noticed it because I was changing branches and didn't see that file in my modified list, and wondered where it went. Then I found it in that previous commit. I'm happy to have it merged into develop, so I'll put it back. |
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 openwebwork#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.
This PR corrects an error where the
eval()method of a Fraction MathObject would return a perl real rather than a MathObject Real. That lead to comparisons that didn't use the fuzzy tolerances, which in turn lead to values that differ by small round-off errors being considered not equal when they should be equal. E.g., Fraction(-25,3) not equaling (8/3)*(-2)-3.This also changes the
compare()method to use a better comparison for fractions, and a more precise tolerance value for comparing a fraction and a real, given by the newfractionToleranceflag. Comparisons between a fraction and anything other than a fraction, real, or infinity will produce error messages.This resolves issue #1204 without making it too easy to use a decimal value to match a fraction.