plot2d failed to plot too many discrete points

Robert Dodier <robert.dodier at gmail.com> writes:

[...]

> Some investigation shows that SBCL's implementation of COPY-TREE fails
> for long lists. Here's what the CL spec says about COPY-TREE: "the
> result is a new cons of the results of calling copy-tree on the car and
> cdr of tree."
> (http://www.lispworks.com/documentation/lw60/CLHS/Body/f_cp_tre.htm)
>
> Here's an example. X is a list of 65536 elements. SBCL 1.0.49 on Linux.
>
> ----- begin output -----
> * (setq y (copy-tree x))
> INFO: Control stack guard page unprotected
> Control stack guard page temporarily disabled: proceed with caution
>
> debugger invoked on a SB-KERNEL::CONTROL-STACK-EXHAUSTED in thread
> #<THREAD "initial thread" RUNNING {AA8F9A9}>:
>   Control stack exhausted (no more space for function call frames).
> This is probably due to heavily nested or infinitely recursive function
> calls, or a tail call that SBCL cannot or has not optimized away.
> ----- end output ------
>
> COPY-TREE is called eventually from plot2d([discrete, ...]).
> See src/plot.lisp (there is only one call to COPY-TREE there).

Thanks, this is exactly the problem for me, the stack also shows
many recursive COPY-TREE being called.

> To the developers: is there any reason to prefer COPY-TREE to COPY-LIST
> in src/plot.lisp?
>
>> I'm considering to output these numbers to a pipe and spawn the
>> gnuplot myself, is it recommended?
>
> One possibility is to write the numbers to a file, then you can
> experiment with different ways to plot them. 
>
> Or edit src/plot.lisp to replace COPY-TREE with COPY-LIST, load(plot);
> in your Maxima session, and try again.
>
> Incidentally, it appears that formatting floats for output is pretty
> slow in all of the Lisps that I've tried today (SBCL, ECL, CMUCL,
> Clisp). If you have a million points, you might end up waiting a long
> time (several minutes, I'll guess) for Maxima to construct the Gnuplot
> data.

Tried, and seems reasonable for 65536 points; displa that takes
like several tens seconds, and slowed down my Emacs quite a bit.

-- 
Carl Lei (XeCycle)
Department of Physics, Shanghai Jiao Tong University
OpenPGP public key: 7795E591
Fingerprint: 1FB6 7F1F D45D F681 C845 27F7 8D71 8EC4 7795 E591
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <http://www.math.utexas.edu/pipermail/maxima/attachments/20120514/4bcf095d/attachment.pgp>;