plot2d failed to plot too many discrete points

On 5/13/12 1:19 PM, Robert Dodier wrote:
> On 2012-05-12, XeCycle <XeCycle at Gmail.com> wrote:
> 
>> I'm trying to plot my computed numbers, roughly millions; then I
>> found plot2d failed to plot these many points.  Even, it failed
>> to plot 65536 points --- should I check my compiler?
>>
>> I'm using SBCL on x86_64 Linux, and the plot function was called
>> From Lisp.
> 
> 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).
> 
> To the developers: is there any reason to prefer COPY-TREE to COPY-LIST
> in src/plot.lisp?

Maybe because it's not a list but a tree (or a list of lists)?  I didn't
look closely to see if that matters or not.

I'm sure the sbcl folks would fix such a bug very quickly.


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

I know sbcl and cmucl have fairly slow float printers because both try
pretty hard to make sure the output is printed in a way that when read
in the same number results.  Probably doesn't matter if you're using
format with less than full precision, but I think there's only one
routine that does the conversion.

Ray