MathView overzealously texifying #638
Comments
|
MathView renders whatever students put in the answer box using MathJax. Unfortunately there isn't a lot of information available on the js side for MathJax to determine what strings are special for a given problem or what they should translate to. Basically, given that all different answers are typed into a text box, it is difficult to tell if a given sequence of characters should be rendered as mathematics or as text. Some options I can think of would be
|
|
I think the problem is actually that MathView uses MathJax's AsciiMath format to parse the student answer, and although AsciiMath is similar to WeBWorK's algebra notation, it is not identical. In particular, AsciiMath includes many more symbols than WeBWorK does. For example, AsciiMath has all the Greek letters (via A solution might be to have the MathJax configuration for MathView remove all the unwanted symbols from AsciiMath (and perhaps add "inf" and "infinity" for \infty, and perhaps set |
|
I had not thought about removing the unwanted asciimath symbols, but that would also be necessary. I already change ** to a power and not a star, so the pathway for these changes are there. |
|
One has exactly the same issues with "Show Past Answers" for the same reason. See the discussion at http://webwork.maa.org/moodle/mod/forum/discuss.php?d=3771 |
|
I agree with Arnie; I prefer to see what the student actually typed, not a typeset version. |
|
Sorry. I just thought that having it easier to read would be worth it |
|
Could it be a choice? Perhaps a toggle on the page that would switch between the views? I'm sure there are people who prefer the typeset version (or at times do). |
|
The other possibility is an overlay. In responding to entries for the current problem I chose one version (usually typeset mode) and allowed you to get the direct input as a popup by hovering over the field. This wasn't enough for some people :-) but it allowed access to the alternative format. |
|
One problem, and the one Gavin first reported, is that in some cases you can not tell the difference between typeset mode and direct input if you are not specifically testing for this (and most instructors would have no reason to). If you look at the forum post, Gavin did not figure out what was going on (he didn't look hard) and it took me quite a while and a wrong guess to become aware that MathJax was the "problem" which was confirmed by Davide. In Gavin's case, Past Answers showed the answers sin(.25x), sin e(.25x), sin(.25x), and sin(.25x) and only the last answer was marked correct by WeBWorK. As Gavin reported the actual answers the student submitted were Sin(.25x), Sine(.25x), Sin(.25x), and sin(.25x). An instructor less knowledgeable about WeBWorK than Gavin would probably conclude the student entered the correct answer (sin(.25x)) and WeBWorK marked it wrong and, for some strange reason, the last time the student entered the correct answer, it was accepted. As noted in one of my and David's forum posts, right now you can easily see the actual answer the student entered, but it's not an obvious thing for an instructor to do (Gavin didn't do it and neither did I until the very end). So, if we do have a typeset mode, I would definitely want the raw input mode to be the default. |
|
Another comment is whether (especially for MathView) it is feasible to substitute the WeBWorK's parser for MathJax's AsciiMath parser? |
|
MathJax runs in the browser, which means it is Javascript, but WeBWorK's parser is on the server in Perl. It would require a complete port of MathObjects to javascript to make that possible. With MathJax v2.6 (currently in beta), it would be possible to use MathJax-node to process the math on the server to produce the HTML that MathJax would create in the browser. That could be cached just like the current image mode results. That doesn't help MathView, but it could be useful for past answers, as well as for problems in general. |
|
The main issue with having a "switch" to turn typesetting on and off is that it doesn't really solve Arnie/Gavin's problem. If you suspect that its the actual answer text that is the issue you can already right click on the typeset formula to see the original answer. The issue is that unless you know or suspect that the raw answer is the problem you would never think to do that, and you wouldn't think to turn off typesetting either. Maybe building a typeset mode for mathjax which more closely mimics PG would solve the issue because it would fail on things like Sin(.25). |
|
What I had in mind was more of a preference so that people could see the form they wanted, not something intended to solve Gavin's problem directly. As for a MathJax input that is more like MathObjects, the difficulty is that what parses and what doesn't is dependent on the answer's Context object, and that varies considerably from one context to another. E.g., in the vector contexts, "<" and ">" are delimiters for vectors, but in the Inequalities context, these are less-than and greater-than. You can't tell which way "<" and ">" are to be treated without knowing the context, so in order to make that work, you would need to have a tighter connection between the page displaying the math and the problem from which the answers came. My main objection to typesetting the answer has always been that you don't have that connection, so will misrepresent answers that are not in the basic numeric contexts. Things like currency, or scientific notation, or permutations, or other special-purpose contexts may not render correctly without the specialized knowledge of the context that the problem has but the instructor page doesn't. |
|
Returning to this after a long hiatus. @dpvc suggested that to address the MathView issue, we could remove all the unwanted symbols from AsciiMath and add a few WW-specific items back. I've looked around the MathJax and AsciiMath documentation, but I can't find how to remove things that the AsciiMath parser recognizes. Can you point me in the right direction? I did find how to change things that the parser already recognizes, following Geoff's note above about I also believe I have found how to add new things, like make it recognize |
|
@Alex-Jordan, I think if you replace lines 23 to 32 by Note that line 32 should be deleted, as it is both unnecessary and syntactically incorrect. That should remove all the existing symbols in AsciiMath and replace them with the ones that correspond to the standard MathObjects "Full" context. It should cover the needs of all the default contexts, but won't properly handle ones like inequalities (since that defines additional operators for the relations Yes, you do need to do the various capitalizations, as AsciiMath doesn't have a case-insensitive mode. I've included See if that doesn't do more what you want. |
|
Thanks Davide. I was going to go through that list in Default.pm myself once I had the basics, but you spared me that. I added I thought I had this all working, but then at the end it appears to work with Chrome, but not Firefox or Safari. Chrome is honoring the MathJax configuration for MathView separately from the configuration for the rest of the WW page. But with both Safari and Firefox, MathView's use of MathJax appears to use the ambient MathJax configuration instead of this specially built one. You can try this live problem in the different browsers and see. In Safari, the draggability is broken, so instead of using the menus, just open MathView and type |
|
@alex, I expect the issue is that the configuration is coming at the wrong time; configuration blocks are supposed to appear before the script that loads MathJax.js itself, and different browsers act differently if that isn't the case. I see that In any case, I think the way that MathJax is being handled in these pages may need to be rethought. Fir one thing, there are two script tags that load MathJax. While MathJax is smart enough to ignore the second call, it does cause some browsers to load the MathJax.js file more than once, which is inefficient. MathJax can be configured to not do its start up until all the configuration has been completed, so it may be worth switching to that mode (it would also involve adding a call at the bottom of the page to tell MathJax that all the configuration is complete). Alternatively, more care could be made to insert the configuration as actual configuration blocks, and make sure they MathJax.js is loaded after that has occurred. That would take a little more care. |
|
OK, for one thing, I pulled MathJax. It was on some 2.6 version. The "free-standing" problem at my earlier link is loaded using the framework of It's one thing to do this with Is there any downside to the delay-until-configured scheme? |
Well, it does mean that MathJax won't start loading its dependencies (like the config file and any font files) until the end of the page is reached (as opposed to right away when its script tag is processed). But because WeBWorK problems are generally pretty short and don't have a lot of other scripts to load, I don't think this will be an issue. If there were lots of images, scripts, and other external resources, since most browsers limit the number of simultaneous connections they will make, it could mean Mathias has to wait for other content to arrive before it can start downloading its configuration and other files, and so delay the processing of Math. That is really the only drawback that I can see. I think this is probably the easiest approach to getting git to work. On the other hand, the MathView configuration is still technically being done in the wrong way, and you are relying on some delicate timing interactions to make it work. It is running in a jQuery ready function, and you are counting on MathJax having to wait for its configuration files and so on to cause a delay long enough to allow the ready function to run before MathJax does its configuration. There is no guarantee that that will happen. It would be better if MathView.js would insert a |
|
I think this is probably the easiest approach to getting git to work.
Well, it seems like I have it working the way I want it to work for my
server, but it feels fragile and not something I should commit and make a
pull request for. The MathJax config is stored in a defaults.config
variable, `$webworkURLs{MathJax}`. The default value is
`"$webworkURLs{htdocs}/mathjax/MathJax.js?config=TeX-MML-AM_HTMLorMML-full"`.
So in localOverrides.conf, I changed it to
`"$webworkURLs{htdocs}/mathjax/MathJax.js?config=TeX-MML-AM_HTMLorMML-full&delayStartupUntil=configured"`.
But then there needs to be the call at the bottom of the page to signal the
configuring is complete. The only place I could find to put this is in the
math4 _theme_, in the system.template and gateway.template, where I put:
```
<footer>
<script type="text/javascript">
MathJax.Hub.Configured()
</script>
</footer>
```
And this is what I mostly don't feel good about. It's an important call to
make that shouldn't be in the hands of a theme. Also, in math4 I see
simple.template and lbtwo.template, which I don't know what these are for.
But I added the footers there too. And then should I bother with math3? And
what about schools that made their own theme copied from math4, that won't
have the footer?
I'm going to see if I can get by with this for our server, but I don't
think it is a real solution for everyone yet.
…--
Alex Jordan
Mathematics Instructor
Portland Community College
|
|
It sounds like you have made good progress on this. I've looked through the webwork2 code, and there are 6 files that use the MathJax variable that you are changing:
webwork2/lib/WeBWorK/ContentGenerator/GatewayQuiz.pm
webwork2/lib/WeBWorK/ContentGenerator/Instructor/PGProblemEditor2.pm
webwork2/lib/WeBWorK/ContentGenerator/Instructor/PGProblemEditor3.pm
webwork2/lib/WeBWorK/ContentGenerator/Instructor/ProblemGrader.pm
webwork2/lib/WeBWorK/ContentGenerator/Instructor/ShowAnswers.pm
webwork2/lib/WeBWorK/ContentGenerator/Problem.pm
so one solution would be to modify these to include the MathJax.Hub.Configured() call. That could be done through another variable that defaults to blank, but that you override to include the call when you override the URL to include delayStartupUntil=configured. That is a bit inelegant, but would work.
One thing to note is that you should be able to put the MathJax.Hub.Configured() call into an onload handler, so you should not need to insert it at the bottom of the page directly. That means that those 6 files could have the Configured() call at the same location where the MathJax.js file is loaded.
There is an alternative, however, which is to replace the call to MathJax.js by a call to a separate .js file of your own that does two things:
1. Loads the actual MathJax.js file (by inserting a script that loads MathJax.js
2. Sets up the onload handler to call MathJax.Hub.Configure()
Then set $webworkURLs{MathJax} to point to your new .js file.
For (1), you could simply use document.write() to insert a script tag, but it is probably better to use document.createElement('script'), set the src attribute and then use document.head.appendChild() to insert it. Note, however, that this means MathJax will be loaded asynchronously, so you can't tell when the MathJax variable will be available. That means that code that refers to MathJax needs to be careful about how it does that. For example, the MathView.js file might need to be changed (I haven't looked at it this morning to check), since MathJax is not guaranteed to be available even when the onload event fires.
For (2), you would need to have the onload handler check for MathJax being available before calling MathJax.Hub.Configured, and if it is not available yet, you could either use setTimout() to try again in a bit, or use the alternative method of configuring MathJax by setting
window.MathJax = {
AuthorInit: function () {
MathJax.Hub.Configured();
}
};
so that when MathJax does load, it runs the AuthorInit function that indicates that MathJax is configured.
But I think there is an easier way (which I'm sorry I didn't think of earlier). There is another option for delayStartupUntil, which is delayStartupUntil=onload, which delays the configuration until the page's onload handler is fired. That should do what you need without requiring an explicit MathJax.Hub.Configured() call. I'm afraid I had forgotten about that option until just now when I was looking at the MathJax code to make sure the calling MathJax.Hub.Configured() from the AuthorInit function would be OK.
So I think if you just change to
"$webworkURLs{htdocs}/mathjax/MathJax.js?config=TeX-MML-AM_HTMLorMML-full&delayStartupUntil=onload";
that should be enough. In fact, it could easily be the default in defaults.config.
|
|
#2296 addresses the important issue here, with users trying to write infinity. I'm going to close this (currently oldest open) issue. |
MathView is turning "in" into the "element of" symbol as in
\in. So for example, a student typinginforinfinityis seeing output of the form\in for\in f\in ity.Not sure if it there are other scenarios as common as "inf", but it also does this for other strings. So if there were a string answer "topology", it is showing you output from
\top o\log y.Is this just a configuration issue? If so, where is MathView configured?
Or maybe it's just assumed that with string answers, the student doesn't activate MathView?
The text was updated successfully, but these errors were encountered: