Forum archive 2000-2006

Nandor Sieben - Strange TeX error

Nandor Sieben - Strange TeX error

by Arnold Pizer -
Number of replies: 0
inactiveTopicStrange TeX error topic started 6/6/2005; 11:26:14 PM
last post 6/10/2005; 9:04:09 AM
userNandor Sieben - Strange TeX error  blueArrow
6/6/2005; 11:26:14 PM (reads: 2229, responses: 15)
Could someone explain what the problem is with $a ? The picture generated for it is not visible. $b works fine. It's possible to fix $a by putting a acdot before \cos x or by replacing \cos x with \cos(x) or by writing \cos x \tan x or by writing \cos t. Somehow \cos x is trouble. Similar problem can happen with \cot x. What is going on? Nandor

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

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

BEGIN_TEXT

\($a\)

\($b\)

END_TEXT

<| Post or View Comments |>


userNandor Sieben - Re: Strange TeX error  blueArrow
6/6/2005; 11:29:46 PM (reads: 2432, responses: 0)
Sorry but the backslashes disappeared before the ( signs. I don't know why, probably my browser swallows them. It's

BEGIN_TEXT

backslash( $a backslash)

END_TEXT

<| Post or View Comments |>


userMichael Gage - Re: Strange TeX error  blueArrow
6/6/2005; 11:48:36 PM (reads: 2442, responses: 0)
The bulletin board swallows backslashes -- I have doubled the backslashes in your post so that they appear. I can't trouble shoot this tonight, but here a couple of ideas. One is -- try doubling the backslashes. The other is that there may be subtle differences in the way cos, tan, sin and cot are parsed -- although it appears to me that you are only using these variables for tex, so they should not be parsed by perl.

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 |>


userNandor Sieben - Re: Strange TeX error  blueArrow
6/7/2005; 12:42:37 AM (reads: 2457, responses: 0)
I could not find a combination that works, not even the here document. Switched to $c and $d, but it didn't help. Double backslash makes it worse. The tangent is on top of cosine. You are right single quote does have escape characters. I didn't realize that, so I am a little confused now. I have no idea what actually happens inside \( \) with the escape characters. Could it be that cos and cot both start with \c that has a special meaning. What really is troubling though is why the different fixes work ( the parentheses around x, changing x to t, the cdot ). They do completely different things.

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 |>


userDavide P. Cervone - Re: Strange TeX error  blueArrow
6/7/2005; 8:47:52 AM (reads: 2461, responses: 0)
I am unable to reproduce the problem here; I get good images in both cases. I wonder if you have a bad image in the image cache. You might try emptying the image cache, or look up the image by viewing the source and then removing just that one image (if you don't want to wipe out the whole cache).

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 |>


userJohn Jones - Re: Strange TeX error  blueArrow
6/7/2005; 4:20:58 PM (reads: 2453, responses: 0)
Hi,

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 |>


userNandor Sieben - Re: Strange TeX error  blueArrow
6/7/2005; 6:45:25 PM (reads: 2443, responses: 0)
remove_stale_images fixed the problem. Thank you very much. Nandor

<| Post or View Comments |>


userJohn Jones - Re: Strange TeX error  blueArrow
6/7/2005; 8:02:25 PM (reads: 2443, responses: 0)
So now we know that you had a bad image, and you kept seeing the cached copy of that bad image until it was removed.

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 |>


userNandor Sieben - Re: Strange TeX error  blueArrow
6/8/2005; 12:27:21 AM (reads: 2402, responses: 0)
I understand, thank you for the explanation. This is exactly what happened. Is it a good idea to run a cron job to do remove_stale_images? If yes, how often? Nandor

<| Post or View Comments |>


userDavide P. Cervone - Re: Strange TeX error  blueArrow
6/8/2005; 7:02:10 AM (reads: 2431, responses: 0)
John:

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 |>


userJohn Jones - Re: Strange TeX error  blueArrow
6/8/2005; 11:05:04 AM (reads: 2446, responses: 1)
Hi,

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
becomes
cos@xy

John

<| Post or View Comments |>


userNandor Sieben - Re: Strange TeX error  blueArrow
6/8/2005; 11:15:14 AM (reads: 2422, responses: 0)
I think it is safe to remove all spaces between an alphabetic and non-alphabetic character, for example between a and 2, a and ), = and a. One space should be left between two alphabetic characters. Nandor

<| Post or View Comments |>


userArnold K. Pizer - Re: Strange TeX error  blueArrow
6/8/2005; 11:58:30 AM (reads: 2443, responses: 0)
Hi,

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 |>


userDavide P. Cervone - Re: Strange TeX error  blueArrow
6/8/2005; 2:59:03 PM (reads: 2695, responses: 0)
John:

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 |>


userJohn Jones - Re: Strange TeX error  blueArrow
6/9/2005; 2:54:35 PM (reads: 2432, responses: 0)
Hi,

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 |>


userArnold K. Pizer - Re: Strange TeX error  blueArrow
6/10/2005; 9:04:09 AM (reads: 2455, responses: 0)
Hi,

I would vote for the simple and safe method. Also this will probably be a tiny bit faster than a more complicated search and replace operation.

Arnie

<| Post or View Comments |>