Re: Plans for gnuplot version 5

[Jon G. <jo...@th...>]

> Have you looked at the proposed patch 
> "Multiplot auto layout with explicit margins and spacing"?
> 
>     https://sourceforge.net/p/gnuplot/patches/611/
> 
> Your feedback or testing would be valuable, and I think the patch could
> be added to the code base either before or after the next release if
> people want it.

Ah, no, I had not seen that. Will have a look once I have the time!

> > Another item that is high on my wishlist is to make multiplotting
> > multithreaded.
> 
> I am not sure I understand what you are asking for there.
> Many terminals allow you to embed the gnuplot output into a
> larger window or document.  You can use this to tile many plots,
> each created or managed by a separate gnuplot instance, rather
> than creating a single multiplot.  
> Is that what you have in mind?

Not quite.
For example, I have a plotting script that plots ~90k datasets using the
animated gif terminal. That is, I call "plot" 90k times in a single
gnuplot session, and each one becomes a frame in the resulting animated
gif. However, at the moment, these datasets are plotted sequentially,
and so although I have a 24-core machine, only one core is doing the
plotting. Ideally, each core would be responsible for some subset of the
plots, and then they would all be merged at the end.

The same applies to creating a multiplot containing hundreds of plots;
at the moment they are plotted one after the other, whereas they could
theoretically be plotted in parallel. I am not familiar with the tiled,
embedded plotting you mention, but although it might solve this latter
problem, it certainly won't solve the former.

> > Finally, native support for dynamic plots would be great.
> 
> I have a patchset that implements this.
> I can dust it off and put it up on SourceForge for you to test if you like.

That would be great!
I'm working toward a deadline this week, but will hopefully be able to
take a look next week.

> In actual testing I was very disappointed with it, so I didn't pursue it.

How come?

> > >  * The high byte of RGB color values is now interpreted as an alpha value.
> > 
> > It seems to me that standardizing on something people might be familiar
> > with is the way to go here.
> 
> Please expand on this suggestion.
> 
> Currently (version 4) you can plot with RGB colors by saying, for instance
>    plot  ... using 1:2:3 linecolor rgb variable
> where input column 3 contains 24-bit RGB values.
> Bits 25-32 are ignored, and the lines are all solid color.

Ah, I see, I was thinking of literal RGB values (#AARRGGBB), not their
binary representation. Hence also my reference to what seems to be
"common".

> Are you suggesting that any command using the keyword "rgb" should
> ignore the high bits?
> I.e. that a new keyword rgba or argb should be introduced everywhere?
> And than what - the program would invert the high byte during input?

Yes, that seems like a sensible approach to me. Particularly so because
it will never surprise a user who is expecting RGB, but suddenly gets
RGBA. In fact, even if you don't invert the high bytes, I think the
choice to use an alpha channel should be explicit.

> > >  * Binary and ascii matrices now support mostly the same set of formats,
> > 
> > While I have little experience with using the binary format, I feel one
> > missing part of the matrix format has always been the ability to plot
> > each pixel individually (give x,y,z explicitly for each row) rather than
> > to require a certain organization of rows/columns. Thoughts on this? It
> > might not be relevant for this discussion though...
> 
> That is currently (version 4.7) supported as
>     plot ... binary nonuniform matrix

No, that's not quite what I meant.
I would like to have a format that lets me specify x and y explicitly in
each row along with the data. This would be particularly useful if it
also allowed data to be given out-of-order (that is, without necesarily
giving it column-wise or row-wise). I suppose that is only really
applicable to the ascii format though.

> It is an example of the inconsistency of the ascii and binary keywords,
> since the binary case needs an extra keyword to specifiy what is 
> already the default in the ascii case.

I think these kinds of inconsistencies, while occasionally annoying, are
not worth breaking backwards compatability for alone. That said, now
that the decision has been made to break it anyway, sorting them out is
a good idea. Personally, I think the default matrix format (ascii or
binary) should be something like the aforementioned with explicity x and
y as that more closely matches the way input data is given to gnuplot
for 2D datasets. I think the most important thing is have the same
keywords and defaults for both formats though, whatever that format ends
up being.

Jon