Re: multiple plot lines with plot '-'

[Allin C. <cot...@wf...>]

On Thu, 17 May 2012, Ethan A Merritt wrote:

> On Wednesday, May 16, 2012 04:41:25 pm Allin Cottrell wrote:
>> I'm envisaging, say,
>>
>> m = {1,2,3; 4,5,6; 7,8,9}
>>
>> where (just for illustration) I'm assuming a matrix syntax in which
>> ',' is the column separator and ';' is the row separator.
>
> Only numerical data?
> That really seems like it's a separate request - to support numerical
> arrays as a variable type.  In certain cases it might substitute for
> a mechanism of caching the input stream, but it would be less general.

OK, point taken.

> My inclination is to think about caching multiline character input
> rather than numerical arrays.  Somewhat along the lines of the patch
> that Dan Sebald mentioned, although as I recall that dealt with caching
> input from a normal data file rather than offering a new mechanism
> of providing data in-line.
>
> Something like
>
> gnuplot> store DATA1 <<EOF
> Paris   France  2110420 48.86°  2.34°
> Marseille       France  820729  43.31°  5.37°
> Lyon    France  443859  45.76°  4.83°
> Toulouse        France  411768  43.62°  1.45°
> EOF
> gnuplot> plot DATA1 using 5:4:($3 < 5000 ? "-" : strcol(1) with labels

Hmm, I think I like it.

> Questions
> - Would we need sanity checks limiting the size (number of lines?) of
>  the in-line data?

IMO sanity is up to the user. Maybe I have 32 GB RAM (actually I 
don't).

> - How persistant would DATA1 be?  Would we require an explicit command
>  to discard it and free the memory?

I think so (require explicit command).

> - Would all the existing "set datafile" options apply to this in-line
>  input also, or would it get a separate set of options?

I'd say, apply the existing options.

>  [aside] It's really hard to type <tab> characters into the gnuplot
>  input stream, because readline grabs them. So tab-separated data
>  fields could be a problem.

But would anyone really want to do this sort of thing interactively? 
(And even if so, would it really be necessary to support that?)

> - What about binary data?

Ugh, forbidden (should always be forbidden, IMO).

> - Would the stored data act as a normal string for the purpose of
>  string operations?
> - What about the keyword "every"?

Hmm, I pass on those for lack of knowledge of what is done to date.

Allin Cottrell