** Using WeBWorK **

student_ans => $view

This previews the picture in the 'Entered' field in the asnwer table. This works perfectly in the library browser but there is an error when we put this problem into a set. In a set the picture is not updated with multiple submission. The first picture remains unchanged even if we change the submitted edges. The problem works, it accepts the correct answer and rejects the incorrect answer. Only the picture is not updated.

Is there anything done differently in the library browser and in a set? Is it a bug or do we need to change something? Is student_ans a wrong place to put this generated picture?

Nandor

<| Post or View Comments |>

I would suggest that you add a 3 digit number to the address of the file holding the picture. Make the number depend on what is in the picture, so that when the picture changes the name of the file also changes.

Hope this helps.

--Mike

<| Post or View Comments |>

I don't know how to do this. It's not a static image, but a picture generated on the fly with the built in drawing macros so I am guessing that the address of the picture is generated automatically.

I am pretty sure it's not the browser. Here is why. I logged out. I moved to another computer and I used a different browser. I submitted a different answer for this problem. Still the picture I got was the one generated by the very first submission on the first computer. Reload, shift reload, view picture in separate window and reload, nothing works.

We use these generated pictures inside pg files all over. They always work, except in this case where the evaluator creates them. So I think something must be done differently in the library browser and sets when pictures are generated in evaluators or when pictures are displayed in the answer table. I am guessing that we are probably the first trying to put pictures in the answer table.

Nandor

<| Post or View Comments |>

$pic->gifName($pic->gifName()."-$in");

It is still a question: why is this needed in a set but not in the library browser?

<| Post or View Comments |>

In general, webwork tries to use cached copies of on-the-fly graphs to save time. Lots of students doing a graph-laden assignment can cause a pretty large load on the server. It happened to us once.

One stage of the caching mechanism is to distinguish graphs by their names, which contains the student name, problem seed, set name, problem number, and graph number within a problem. If any of those things change, then webwork will generate a different graph. It isn't bulletproof, but collisions here are pretty unlikely. Effectively, someone would have to make an assignment, and then change the pg file used for the problem without changing the seed or renumbering the problems, and both pg files would have to have on-the-fly graphs in them. Webwork also checks the change times of the pg file and the graph, so if there is a new copy of the problem file, it regenerates the graph.

The final check is to see if the problem is being rendered from the library browser. Those problems have only generic data (problem seed is usually 0, set name is always the same, etc.). So, while someone is browsing problems with graphs, it is pretty likely that this data will result in a name collision. So, the caching mechanism accounts for it. So, that is why rendering on-the-fly graphs was different in the library browser.

Manually changing the graph name like you are now doing is probably the right solution. Any other solution would either mean giving up on caching or setting a flag for certain images (like yours) to say "don't cache me", but the latter is as much work for the problem author as what you have above.

John

<| Post or View Comments |>

Over the long term you may need to worry about filling up the directory where these images are stored (since there is no reuse of images). This won't be a problem in the beginning but eventually you might like to set a cron job to clear these images out. Using time() as part of the name makes it easy to tell how long ago the image was created.

<| Post or View Comments |>

John

<| Post or View Comments |>

Nandor

<| Post or View Comments |>

What might be worthwhile is to generate part of the file name based on the actual contents of the image. That way the same images reuse the same space. This is what we do with latex math images. With these images we have natural data to generate the hash.

I suspect that with png files we could use MD5 (http://userpages.umbc.edu/~mabzug1/cs/md5/md5.html) to generate a 128 bit signature for the image.

I don't know what the performance costs would be, but the idea behind the implementation would be quite straightforward.

By the way -- the latest version in the CVS has refined time measurements (to 1/1000 of a second) so that it's easier to measure the affect of a change on performance.

<| Post or View Comments |>

For Mike, I am a little unclear on your suggestion. The current idea is to not generate an on-fly-graph if we don't need to. If our test for whether or not we need the image is: generate the image and run md5 on that, we can't be saving any time. It would save some disk space if two different students produced exactly the same graph in their problems, but it probably isn't worth it for that.

Otherwise, you have to run md5 on the data used to generate the graph. For latex images, it is easy to get ahold of that data. However, for WWPlot objects, I don't think there is a function for that yet, and it doesn't sound like much fun to write. Of course if we added a function to serialize the graph, then we could use md5 on the result. We also wouldn't need to incorporate any other information in the filename of the graph since, if two graphs were generated by the same data, they better have the same image.

John

<| Post or View Comments |>

-- Mike

<| Post or View Comments |>

I'll add my two cents to this discussion. We already have the "flag" refreshCachedImages. I'm not 100% sure what this does in WW2 but I assume it means that if a problem contains $refreshCachedImages =1 then dvipng images of equations are not cached but are refreshed every time. I think what we should do is to refresh all cached images if this flag is set. Maybe it even does this now. Having a problem author remember to reset the name of the stored image, etc. is too complicated and to remember what $refreshCachedImages =1 does is even worst if it doesn't refresh all cached images (at this point I at least don't remember). Here's the verbiage from PG.pl.

The following flags are set by ENDDOCUMENT:
(1) showPartialCorrectAnswers -- determines whether students are told which
of their answers in a problem are wrong.
(2) recordSubmittedAnswers -- determines whether students submitted answers
are saved.
(3) refreshCachedImages -- determines whether the cached image of the problem
in typeset mode is always refreshed (i.e. setting this to 1 means cached
images are not used).

Arnie

<| Post or View Comments |>

<| Post or View Comments |>

In any case, it does seem reasonable to have refreshCachedImages act as Arnie suggests, so it has its old meaning plus refreshing of on-the-fly graphics images as well.

John

<| Post or View Comments |>