Thank you very much. My previous solution based on Robert's insights was
to do an arbitrary but long-lasting "for" loop that kept Maxima busy so it
didn't overwhelm Gnuplot (which I forgot to reply-all when I explained it,
so I didn't send it to the maxima email address). This worked, but it was
very CPU intensive and slow. This new solution is much faster and easier.
And I would have never guessed it myself. It also works in the specific
draw3d command that brought this problem to my attention to begin with.
Now I can continue my graduate project.
Thanks again, I really appreciate both of your guys' help.
--Andrew
On Fri, Nov 18, 2011 at 1:28 PM, Mario Rodriguez <biomates at telefonica.net>wrote:
> El vie, 18-11-2011 a las 08:51 -0700, Robert Dodier escribi?:
> > On 11/18/11, Andrew Norman <anorman728 at gmail.com> wrote:
> >
> > > It took me awhile to condense my problem down to something quick and
> easy
> > > to explain. Using the draw package with multiplot_mode(screen) and
> > > set_draw_defaults(xrange=[-10,10],yrange=[-10,10]), if I define a
> function
> > >
> > > b(k):=
> > > for j:-10 thru 10 do
> > > draw2d( points( [ [ j,k ] ] ));
> > >
> > > It should (and it does) create a line of points along the line y=k.
> But if
> > > I then evaluate
> > >
> > > for k:-10 thru 10 do b(k);
> > >
> > > Then it works (mostly) for the first couple of lines, but then it skips
> > > almost all of the points.
> >
> > My first guess (emphasis on guess) is that this is the result of a
> > race condition: many plotting commands write to temporary files
> > and then those files are processed by Gnuplot. Maybe the output
> > from one iteration is clobbering another before Gnuplot has a
> > chance to read it? What happens if you put in a delay, e.g. read();
> > (then you have to enter something like "0;" to continue).
>
> > There might be a way to tell draw to pipe the data directly to Gnuplot
> > without using a file. I don't know how to do that.
>
>
>
> Hello,
>
> I can take a look at it. In fact, in the first versions of draw, data
> were sent to Gnuplot via the pipe.
>
> But writing the coordinates in separate files, thus avoiding
> interferences, gives the same wrong behavior. We also need to write the
> gnuplot scripts in different files to get acceptable results. So let's
> play with options 'data_file_name' and 'gnuplot_file_name'.
>
> The problem with this workaround is that a lot of files will be
> generated.
>
> Andrew, you can try something similar to this session:
>
>
>
> /* Create a temporary file */
> system("mkdir tmp_maxima") $
>
> /* tell Maxima where to place temporal files */
> maxima_tempdir: "tmp_maxima" $
>
> /* load draw and set defaults */
> load(draw) $
> set_draw_defaults(xrange=[-11,11],yrange=[-11,11]) $
>
> /* write the plotting function */
> b():=
> for j:-10 thru 10 do
> for k: -10 thru 10 do
> draw2d( data_file_name = sconcat("data_",j,"_",k),
> gnuplot_file_name = sconcat("gnuplot_",j,"_",k),
> points( [ [ j,k ] ] ));
>
> /* set plot mode and call b */
> multiplot_mode(screen) $
> b() $
>
> /* remove the temporary files */
> system("rm -r tmp_maxima") $
>
>
> When I remove one of the options 'data_file_name' or
> 'gnuplot_file_name', gnuplot starts its random behavior just in the
> moment when the outer loop of 'b' returns the message 'done' and the
> Maxima prompt appears again. But using the two options, even when 'b'
> terminates, Gnuplot remains plotting the points normally. You can make
> further calculations with Maxima while Gnuplot is still working.
>
>
> --
> Mario
>
>