** Using WeBWorK **

$a='\tan x \cos x';

$b='\tan x \cos(x)';

BEGIN_TEXT

\($a\)

\($b\)

END_TEXT

<| Post or View Comments |>

BEGIN_TEXT

backslash( $a backslash)

END_TEXT

<| Post or View Comments |>

Backslashes are interepreted, even by the single quotes in perl, so you have to be careful. Every evaluation of a string removes a level of backslashes.

(The perl "here document" equivalent of single quotes does not appear to remove backslashes e.g. <<'EOF' ....... EOF seems to protect backslashes on most implementations of perl -- I'm not sure why since my interpretation of the perl documentation is that the here document version and the single quote version should behave identically. )

In any case experimenting with using two backslashes instead of one will probably cause different behavior (better or worse).

You can try to view the problem using hardcopy and asking for TeX output instead of PDF output -- this will give you some idea of what the $a and $b variables have become by the time the TeX program sees them.

One final thought, although it is probably not happening in this case. For historical reasons perl uses $a and $b as special variables when doing sorting. I have occasionally seen a weird problem fixed when I replaced $a and $b by $c and $d. :-)

Hope this helps.

Take care,

Mike

<| Post or View Comments |>

If I turn off automatic loading of pictures then I see that the tex code is what it needs to be. Similarly I can see the tex code by moving the mouse onto the image. This doesn't work though in this case because simply there is no image after loading the images. This is really confusing. Nandor

<| Post or View Comments |>

What happens if you view it in jsMath mode? Or as formatted text? Does it show up properly in hardcopy?

Davide

<| Post or View Comments |>

As superuser, you can use remove_stale_images --remove --days=0 to remove them all. There isn't much harm to this since they are remade pretty quickly.

If that doesn't cure the problem, maybe post the entire pg problem.

John

<| Post or View Comments |>

<| Post or View Comments |>

The reason "good latex" code matched the bad image is that we remove all whitespace from the latex string and cache images based on that string. So, if you ever had \cosx, produced an image (which would be bad since cosx isn't a latex macro name), then fixed it to \cos x (with a space this time), it will match the bad image. Of course, other variations like \cos(x) would be different as far as the cache is concerned.

John

<| Post or View Comments |>

<| Post or View Comments |>

How hard would it be to not cache images whose LaTeX cause error messages? I can see other people doing exactly what you said above: typeing \cosx accidentaly, then correcting it but not getting a good image. They won't have any way to fix it other than getting their system administrator to dump the whole cache.

Maybe instead of removing spaces, why not just remove leading and trailing spaces, and convert double spaces to single spaces, then use that to determine the cache id. Even in math mode, spaces can sometimes be significant (as we have seen), so this method could cause two different (and correct) pieces of LaTeX code to produce the same id, so one of them would get the wrong image. If there is a reason you can't use spaces in the string-to-id algorithm, how about converting the spaces to something else, like underscores or something?

As you say, remaking images is pretty fast, so I don't see the advantage in trying to eliminate spaces to get more TeX strings to use the same cached image, at least if there is a chance for getting bad images from valid code.

Davide

<| Post or View Comments |>

First, in response to Nandor's question, I don't think people get bad images very often. It should only happen when developing problems, and even then, it is an unusual circumstance. So, cleaning out old images is usually more of a disk space issue.

The days parameter of remove_stale_images is for the last time the file was accessed. So you can set --days=21 to remove images which have not been accessed (by webwork) in the past 3 weeks. Running a cron job to do that every week will keep the most used images, but keep the whole cache down to a moderate size (depending on your system). If you give no arguments, you get a list of the number of images by last access time.

Next, I don't see any problem with having webwork not cache an image which produced an error along the way. I haven't examined the code lately so there might be something I am missing, but I don't forsee any problems.

I think removing whitespace was done soley to recognize more combinations of strings which produce the same image. Missed recognition causes more images to be made, and more stored in the cache. Changing \s+ to a single space would miss f(x)=y, f(x) = y, f( x)= y, etc., as being the same. I am sure that there exist two latex strings which are both legal and differ only in spaces, but produce different output. But, I doubt they happen naturally in webwork problems, which is probably what the designers of equationcache were thinking.

That said, you are right that producing images is fast enough that maybe we shouldn't worry about it. Or, maybe the regular expression for removing whitespace could be made fancier. I don't have the TeX book handy to know exactly what characters are allowed normally in a macro name, but what about changing the first space after a macro name to an @, then removing all space so that

  cos    x y

cos@xy

John

<| Post or View Comments |>

<| Post or View Comments |>

I didn't know we were removing all interior spaces and I think that's a dangerous thing to do. It's much more likely to cause problems than having two different expressions with the same MD5 name. That said, the probability of a problem is still pretty small.

One simple example that comes to mind is r \cdot s (r.s) becoming r\cdots (r...)

So as a quick fix that will certainly work I would opt for removing all initial and trailing spaces and then replaceing all multiple spaces by a single space. Of course that means storing two images for x=y and x = y. I doubt that such things will really add much overhead. If one is really worried about space, then one could try John's solution of replacing all spaces after a macro name by some illegal tex character (is @ suitable?) but then you may have to be careful. E.g how do you reconize macros? I think \\c is legal for a new line followed by a c. I'm not sure the space savings are worth the potential pitfalls.

Arnie

<| Post or View Comments |>

Thanks for the explanation. I agree that trying to recognize different strings that produce the same TeX output is a laudable idea, but it seems that simply removing all the spaces might be too naive an approach. On the other hand, I've never actually run into a case where it mattered; but Nandor did, so the probability is small, but non-zero.

I think Nandor may have the right idea when he suggests removing spaces other than between alphabetic characters. I might also not remove them after open and close braces (where they can also be meaningful, though that is rare), but I think everything else is fine (ignoring the possibility of using hbox within a formula, in which case the spaces are significant).

The @ symbol should be fine to use as a replacement for spaces, but why bother changing it at all? Once you have removed all the removable spaces, do you have to convert the remaining spaces to something else?

Davide

<| Post or View Comments |>

I was suggesting the @ only as a simple way of coding things - replace needed spaces by @, then remove all whitespace. It maybe that we should opt for something simple and safe like all leading and trailing space, and multiple spaces get converted to a single space. I think one could remove more. After all, any spaces left behind is then safer than the current situation which rarely fails. But, maybe it isn't worth it.

John

<| Post or View Comments |>