-
-
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
Attempt to support some standard math operators when included in answers using Unicode characters #517
Comments
The error message I see from this kind of thing is a database error message. Something trying to record the submitted string to the database rejects it. The message is like this:
This was for submitting a |
@Alex-Jordan Was the test course used created as a new course once WW 2.15 was installed on the server? |
Ah, you got it. I just tried on a new course and do not get the error. Now that we're talking about this, I think I previously knew that new courses don't lead to the error, possibly with your help. But I since forgot. OK, is it is as simple as just adding
and it had the desired effect. The answer was 4, and I could enter Unless there would be bad side effects, we could add this (and other similar things) to Parser/Context/Default.pm, effectively adding them to the Numeric context, and then everything downstream that builds off of Numeric. |
I do think I like your other idea better: converting to the keyboard version immediately upon receipt. That would avoid so much duplicate code, and give one place to clearly maintain all such conversions. Like in the year 2025 when some new emoji character is added that resembles an infinity sign, or whatever. But I do not know where that would be handled. On the other hand, if these were handled the other way (as recognized by the context) then problem authors could use them too. For example, with a Mac, I can type |
@Alex-Jordan Thanks for providing the suggestion. Do you know if we can get this to take effect via Otherwise, I may to to make changes to About the "mapping" approach - I suspect that any mapping might need to be handled at the webwork2 level. Another downside of that approach is that we will probably be modifying what gets recorded in the database from what the student actually sent - which I do not think is ideal. |
While the idea of adding more operators to the context would work, it has an important drawback beyond the additional code. If a context needs to be modified, that means you have to know all the versions of the operator that would need to be modified. For example, if you want to disable exponentiation, then you need to know all the characters that are tied to that (there currently are two versions, and that is problematic already). Many existing contexts modify the classes associated with existing operators, so you would need to go through an modify all of those to include any new characters that are added to the context. This seems impractical to me. On the other hand, I would not want to see wholesale remapping of characters one to another outside of the context's control. There used to be some characters that WeBWorK would remove automatically (like dollar signs and other "special" characters), which made it impossible to write contexts that used those characters (like currency answers with dollar signs), and that was impossible to work around from within the problem. Making global replacements like this makes assumptions about the meanings of those characters in the context, and that is something I would not want to encourage. I think the proper way is to extend the MathObject parser to allow operators (and the other items) to allow additional characters that also trigger the same operator. That is, you would only define I would not, however, map U+02C6 (circumflex accent) to All this may lead to requests for U+00B2 (superscript two) to be used for ^2, and so on (there are superscript parens and + and -, so would you want to be able to enter whole expressions that way? What about superscript n (U+207F)?). There are also subscript numbers, so would you want to allow those for entering |
I am not entirely on board with supporting these characters. The majority of the time that students are entering these characters via cut and paste from other websites are cases where students are using websites to get answers to problems in ways that they should not be. I think that it would be better to fix the messages that students are given when these characters are encountered, but to still not accept it as correct. Instead of "Unexpected character '−'", give them some message about not using these methods. At least if we decide to support these sort of characters, it should be made a course option, or something like that. |
When I first encountered these kinds of submissions, I assumed they were
instances of copy-paste from Chegg or something like that. But when I would
investigate, it would come out that it was copy-paste from a WeBWorK
screen. There two scenarios:
* A student /did/ know the answer involved pi or infinity, but genuinely
did not know to spell them out. They would copy the symbols from somewhere
on the problem screen. Or perhaps from a different problem screen where
they remembered those symbols were presented. It should be noted that even
explicit messages that say "type 'pi' for π", etc., could be ineffective
(the student wasn't reading them). This could even happen with a minus
sign. For students of a certain persuasion using a cellphone, I found that
copy-pasting a minus sign is preferable to moving their keypad to the
secondary screen where the hyphen is.
* A student was using Show Me Another to see a different version of the
problem (with solution, answer available) and copied something from the SMA
screen. It's less clear in these situations if the SMA version helped them
learn something, or if they are reverse engineering through copy-paste and
editing numbers, and leaving the fancy minus sign in place.
In my situation, I still have pressure from faculty who would rather use
MyMathLab or ALEKS because to them, there are all these little things that
prop up a confirmation bias for WW's inferiority. (I don't actually know
how the commercial platforms respond to these characters.) So I like the
general idea here. But I wouldn't be opposed to making it configurable as a
special PG environment variable.
…On Sat, Jan 9, 2021 at 1:42 PM Glenn Rice ***@***.***> wrote:
I am not entirely on board with supporting these characters. The majority
of the time that students are entering these characters via cut and paste
from other websites are cases where students are using websites to get
answers to problems in ways that they should not be. I think that it would
be better to fix the messages that students are given when these characters
are encountered, but to still not accept it as correct. Instead of
"Unexpected character '−'", give them some message about not using these
methods. At least if we decide to support these sort of characters, it
should be made a course option, or something like that.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#517 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABEDOACB5YUOZSV4AMFJT2LSZDETLANCNFSM4V3XRUZQ>
.
--
Alex Jordan
Mathematics Instructor
Portland Community College
|
@drgrice1 wrote:
The Unicode minus can be copy-pasted from MathJax equations in the same question, which seems pretty legitimate and innocuous. However, I do agree that if this can be enabled/disabled at the site and course level - that would be optimal. Although there may be some small didactic benefit to forcing students to type their answers themselves, forcing them to do so will not stop some students from utilizing external aides which we would prefer and recommend they not use. About @Alex-Jordan's suggestion about '∞': With MathQuill displaying an '∞' for infinity, it is somewhat hard to tell students that they must type "inf" and cannot paste in the "character" which will be displayed. In many questions it will be in the question text, ex. in the Another recent issue I have noticed in some support request was students using "mixed fraction" notation in answers, and WW treats the integer as multiplying the fraction. I think that is probably best handled by "educating" students about the expectations of syntax used. We have many local problems which explicitly remind students to use The question is not whether to draw some lines about what we want to accept and what not - but where to draw those lines, and to what extent it should be controllable by the course staff.
|
Re: "starting small". I have maybe had one or two instances ever of this happening with the We use the RestrictedDomain context a lot with answers like But every other time this has come up (dozens of times), it has been the minus sign or infinity sign. So starting with those two things would go a long way. One is an operator, so could become the model for alternative operators. (Or I guess Now that I look it up, |
Another common one we have encountered are 'full width' versions of standard punctuation symbols, in particular: We have also seen cases where the student genuinely meant to enter an answer involving pi or infinity but didn't know the syntax so copied the unicode symbol from somewhere. It is also quite easy to generate symbols like π ∞ etc on modern systems, eg you can type '\pi' in MS Word to produce π then copy & paste it. So I think it is worth supporting common unicode symbols. I too like the approach of each math operator having a list of alternate characters that trigger the same operation. I would like to see it configurable at a global or course level though (as well as at individual problem level), so that we can set up our desired symbols once rather than having to remember to set it up in every problem. |
One strategy to impede cheating by copy/paste would be to disable pasting
and similar things for the input field. Like you see in some "confirm email
address" forms.
https://davidwalsh.name/prevent-paste
For the students that are copy/pasting when they legitimately know an
answer (like infinity) this would force them to learn and use the intended
keyboard-only method.
Supporting the ∞ character and some others would still be good because they
can be typed.
…On Sat, Jan 9, 2021 at 6:54 PM awmorp ***@***.***> wrote:
Another common one we have encountered are 'full width' versions of
standard punctuation symbols, in particular:
, U+FF0C FULLWIDTH COMMA
( U+FF08 FULLWIDTH LEFT PARENTHESIS
) U+FF09 FULLWIDTH RIGHT PARENTHESIS
These are used on some Chinese language keyboards instead of the standard
comma and parentheses, so when a student using a Chinese keyboard tries to
type comma or parentheses, they get these 'fullwidth' versions instead,
which Webwork doesn't recognise. I would vote for these being included as
alternatives for comma and parentheses.
We have also seen cases where the student genuinely meant to enter an
answer involving pi or infinity but didn't know the syntax so copied the
unicode symbol from somewhere. It is also quite easy to generate symbols
like π ∞ etc on modern systems, eg you can type '\pi' in MS Word to produce
π then copy & paste it. So I think it is worth supporting common unicode
symbols.
I too like the approach of each math operator having a list of alternate
characters that trigger the same operation. I would like to see it
configurable at a global or course level though (as well as at individual
problem level), so that we can set up our desired symbols once rather than
having to remember to set it up in every problem.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#517 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABEDOAAF3LWYNMZG2K6UB4DSZEJG3ANCNFSM4V3XRUZQ>
.
--
Alex Jordan
Mathematics Instructor
Portland Community College
|
There are questions where copy-paste can be used legitimately, ex. when complicated expressions are needed multiple times in a question. Ex change of variables in a question on integration - where we can ask for the new "ranges" and later use them as bounds of integration, and may ask for the Jacobian in advance and then it may be part of the integrand. I would not want to see copy-pasted disabled by default. Certainly, if we can set it as an option at the course level, that is something to consider. |
I would not want to see copy-pasted disabled by default. Certainly, if we can set it as an option at the course level, that is something to consider.
When debugging a problem, pasting an answer can be very helpful. So if
this were something to do, it could be something that only applies up
to some permission level. Using it for 'guest' could be the default.
(Or perhaps the permission hierarchy should have something lower than
'guest' called 'everyone', the opposite of 'nobody'.)
…On Wed, Jan 13, 2021 at 8:04 AM Nathan Wallach ***@***.***> wrote:
One strategy to impede cheating by copy/paste would be to disable pasting and similar things for the input field.
There are questions where copy-paste can be used legitimately, ex. when complicated expressions are needed multiple times in a question. Ex change of variables in a question on integration - where we can ask for the new "ranges" and later use them as bounds of integration, and may ask for the Jacobian in advance and then it may be part of the integrand.
I would not want to see copy-pasted disabled by default. Certainly, if we can set it as an option at the course level, that is something to consider.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
--
Alex Jordan
Mathematics Instructor
Portland Community College
|
I have made a PR (#518) to implement the alias and alternative token suggestions that I made earlier. It also adds the ability to convert the full-width Unicode characters to their ASCII equivalents (so there is no need to add those as alternatives directly). It may be worth trying that out to see what you think. There are course-wide configuration parameters for these features. The aliasing took a bit of work, but the alternative tokens was pretty straight forward. It would be possible to separate out the aliasing and just do the other changes, if that is desired. |
I withdraw my reservations about this as regards to cheating and such. Your arguments to the contrary make a lot of sense. Furthermore, the instances where I have seen this and suspect foul play are very few. I also would not want copy/paste disabled. I use that, and like @taniwallach I have cases where I have even told students to copy/past answers from other answer boxes. |
@dpvc: Thanks for the pull request. I will try to do some testing with it soon. |
The issue of Infinity printing as '∞' is easily handled by setting the context's
Of course, there may be other symbols that would want to be output using unicode characters (the cross product as U+00D7 rather than |
I've added the |
Note: the MathObject parser would allow the alternative input tokens to be used in the PG problems themselves, but since this is controlled by a course-wide configuration option, if you actually used the alternatives, then your problem would become unusable if the option were turned off for a course. We already have another example of something like this situation: whether Perhaps that doesn't matter, but it is something to keep in mind. |
It should be in the documentation somewhere reasonable prominent. So should the |
Fixed by #518 |
Students in my institution find it quite convenient to sometimes cut and paste pieces of equations shown using MathJax (and from external sites) into the input boxes. Many of them run into problems with Unicode characters being used for standard math operations and get an error message like:
e28892
) https://www.fileformat.info/info/unicode/char/2212/index.htmcb86
) https://www.fileformat.info/info/unicode/char/02C6/index.htmI think we should try to have PG handle these types of Unicode character as alternate forms of the ISO-8859-1 / "keyboard" characters we would expect them to type by hand.
I'm not yet certain where we would do this, and whether it is best accomplished by a replacement in the answer string or by adding the Unicode character are a known math operator in MathObjects.
@dvpc Any thoughts on the best approach?
The text was updated successfully, but these errors were encountered: