plot2d failed to plot too many discrete points

On Sun, May 13, 2012 at 4:54 PM, Robert Dodier <robert.dodier at gmail.com>wrote:

> On 2012-05-13, Raymond Toy <toy.raymond at gmail.com> wrote:
>
> >> 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 think sometimes it's just a list and sometimes it's a more complex
> expression. COPY-TREE is now called to prevent the plotting functions
> from changing the original data. I don't know if COPY-LIST is
> sufficient for that purpose.
>

Maybe instead of copy-tree on the whole tree, it might be sufficient to do
something like

(let ((x (copy-list (third f)))
      (y (copy-list (fourth f))))
  ...)

x and y should be lists, I think.

Ray



>
> > I'm sure the sbcl folks would fix such a bug very quickly.
>
> Reported as: https://bugs.launchpad.net/sbcl/+bug/998926
>
> > 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.
>
> Well, it's entirely reasonable to preserve readability for floats, but
> it does make it less convenient to process a sizeable data set ... I can
> see a couple of things that would make it faster. (1) Gnuplot could read
> binary data so no printing & parsing is needed. (2) Maybe scanf or
> whatever is Gnuplot's number parser could recognize the bytes of a float
> encoded as hexadecimal. E.g. #f4DEADBEEF => some number. Or maybe
> #f8(mantissa,scale,sign) since those fields are conveniently returned by
> INTEGER-DECODE-FLOAT.
>
> (1) and (2) aren't human-readable (for most humans I guess) but it could
> make machine-to-machine communication faster and unambiguous. Yes, I am
> daydreaming here.
>
>
I didn't about this, but a google search found this:

http://gnuplot.sourceforge.net/docs_4.2/node103.html

Getting the supported lisps to dump out binary floating point data
shouldn't be too hard as long as INTEGER-DECODE-FLOAT works and streams
with element type of (signed-byte 32) (or 64?) work.

Ray