gnuplot-beta — Developers and beta testers of new gnuplot code

Re: Make Gnuplot using the mathematical minus sign

[Philipp K. J. <ja...@ie...>]

[snip]

> Although I have never hacked Gnuplot, I am fluent with C/C++ and
> would like to try to write a patch that implements this feature. I
> would like to ask you which would be the best way to do this:
> 
> 1. Implement a pair of commands ("set hyphenminus" / "unset
> hyphenminus") which change this setting globally, i.e., on the
> X/Y/X2/Y2 axes.
> 
> 2. Implement a new formatting sequence, like "%h", which takes care
> of using the correct character.

In that spirit (and sorry for hijacking your
posting): I noticed that the %h and %H conversion
specifiers use an 'x' (letter x) and a '*' (asterisk)
to form numbers like 3.1 x 10^4.

It would be lovely if they used the "multiplication
sign" (U+00d7) and the dot operator (U+22c5 - or
alternatively U+00b7) instead.

I could imagine a general user option for such 
situations, eg:

set character minus <character>
set character times <character>

That would also allow an easy fallback for the 
situation that the user's installed font does
not supply glyphs for the required "special" chars.

> 
> My preference goes to the first option (if one cares for typographical
> correctness, chances are that it wants it on every axis.). Moreover,
> I would like to make the mathematical minus the default, and leave
> the possibility to use the hyphen only as a way to retain backwards
> compatibility (this is what Matplotlib does).
> 
> What do you think? Do you have suggestions about how to properly code
> this?
> 
>   Maurizio.
> 
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media,
> is your hub for all things parallel software development, from weekly
> thought leadership blogs to news, videos, case studies, tutorials and
> more. Take a look and join the conversation now.
> http://goparallel.sourceforge.net/
> _______________________________________________ gnuplot-beta mailing
> list gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Make Gnuplot using the mathematical minus sign

[Ethan A M. <sf...@us...>]

On Tuesday, 27 January, 2015 09:45:35 Maurizio Tomasi wrote:
> Hi to everybody,
> 
>   Yesterday I posted a question on StackOverflow about the possibility to
> use the mathematical minus sign for negative numbers for tick labels in
> Gnuplot instead of the hyphen. (This is a request I got from the referee of
> a paper I've just submitted.)

Some gnuplot terminals already do this, or can easily be told to do so.
For example, in the PostScript terminal this is done by specifying the
appropriate glyph in the encoding table that is part of the Prologue.

What terminal type are you using?

	Ethan

> 
> Although I have never hacked Gnuplot, I am fluent with C/C++ and would like
> to try to write a patch that implements this feature. I would like to ask
> you which would be the best way to do this:
> 
> 1. Implement a pair of commands ("set hyphenminus" / "unset hyphenminus") 
> which change this setting globally, i.e., on the X/Y/X2/Y2 axes.
> 
> 2. Implement a new formatting sequence, like "%h", which takes care of using
> the correct character.
> 
> My preference goes to the first option (if one cares for typographical
> correctness, chances are that it wants it on every axis.). Moreover, I would
> like to make the mathematical minus the default, and leave the possibility
> to use the hyphen only as a way to retain backwards compatibility (this is
> what Matplotlib does).
> 
> What do you think? Do you have suggestions about how to properly code this?
> 
>   Maurizio.
> 
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: with parallelaxes dumps core

[Daniel J S. <dan...@ie...>]

On 01/27/2015 11:44 AM, Philipp K. Janert wrote:
>
> [snip]
>
>>> One comment, though: before going down this
>>> path (of extending the permissible number of
>>> cols in "using") very far, let's consider
>>> whether this is the right way to do it.
>>>
>>> Already, entering 7 explicit col numbers is a
>>> pain. Entering 35 (or whatever) different ones
>>> is simply not practical.
>>
>> Well, as with binary data, it could be that the data file and the
>> command itself are constructed by automation, i.e., a computer
>> program or script.  Plus, it isn't that difficult to build up a long
>> command in an input file using an editor.
>>
>
> Maybe so, but I really consider it a mistake
> to rely on it, ie: designing the UI under
> the assumption that the user automates.

There are plenty of programs that use gnuplot in an automated fashion. 
Large amounts of data isn't something new.  But the parallel axes plots 
can only be so many before spatial resolution is lost.  That is, if 
there were one hundred parallel axes, it would be difficult to resolve 
any useful information between axes.  Then again, if somehow the user 
wanted 100 axes strewn across some really wide bitmap that say is put 
into an HTML viewer so that a scroll bar could be used to scan across 
all axes, then maybe.  In any case, it seems that a dynamic number of 
axes is the way to go.


>> set parallelaxis layout 7,1
>
> I think this is going in a similar direction to what I
> said earlier - treat it as its own beast, but more
> generally. The idea of hitching onto the "multiplot"
> features strikes me as interesting. That might deliver
> the "star plot" application for (almost) free, by the way.

I kind of like that approach instead of putting parallel axes "inside" 
of "plot".  As Ethan's previous post described, the axes thought of as 
an object (structure, pointer) makes a lot of sense.  I'd rather have 
the syntax sort of reflect what is happening internally--somehow that 
seems more flexible, say if the user wants to put data points on the 
axes (writing "with parallelaxes with points" seems dodgy).

Dan

dynamic axex [was Re: with parallelaxes dumps core]

[Ethan A M. <sf...@us...>]

On Monday, 26 January, 2015 19:28:19 Philipp K. Janert wrote:
> 3) The limitation to 7 cols (which, I
> suspect, depends on limitations in the
> way "using" is parsed) puts the entire
> plot style into question.

Somewhat tangential, but here goes.

There are 3 related but distinct limitations:

1) The number of columns read from a data file.
   This is essentially unlimited.  For example:
   plot 'data' using 0:(sum [i=1:999] column(i))
   will happily read 999 columns of input data

2) The number of properties associated with a
   single "point" in a plot.  This is currently 8:
      x y xlow xhigh ylow yhigh z color 
   The first 7 are fields in (struct coordinate).
   The 8th is kept in a separate location, but only
   if the plot involves variable (i.e. per-point) color.

3)The number of fields in a "using" specifier.
  This is currently defined by
     #define MAXDATACOLS (MAX_NUM_VAR+2)
  and is primarily relevant to the "fit" command


However, none of these are the reason for a cap on the number
of parallel axes.  That comes instead from a poor design
decision now lost in the mists of program history.
There is one "struct axis" for each axis holding the
range limits, scaling,  tic information, axis labels, etc.
That's fine.

But the axis parameter passed to all the subroutines
and macros that manipulate this data is not a pointer to
an instance of an axis structure, but instead an index into
the fixed array
    struct axis axis_array[AXIS_ARRAY_SIZE]
This is bad, because you can't just allocate a new
axis structure and pass it to any of the existing 
subroutines or macros.

So the first step towards allowing dynamically allocated
axes has to be refactoring all the code to use an axis
pointer rather than an array index.  Not terribly
difficult, but it touches a huge amount of code.
I think this would be a nice cleanup, but until now
there has not been sufficient motivation to tackle it.

	Ethan

Re: with parallelaxes dumps core

[Philipp K. J. <ja...@ie...>]

[snip]

> > One comment, though: before going down this
> > path (of extending the permissible number of
> > cols in "using") very far, let's consider
> > whether this is the right way to do it.
> >
> > Already, entering 7 explicit col numbers is a
> > pain. Entering 35 (or whatever) different ones
> > is simply not practical.
> 
> Well, as with binary data, it could be that the data file and the 
> command itself are constructed by automation, i.e., a computer
> program or script.  Plus, it isn't that difficult to build up a long
> command in an input file using an editor.
> 

Maybe so, but I really consider it a mistake
to rely on it, ie: designing the UI under
the assumption that the user automates.

> 
> > Should the whole approach be rethought? Is
> > "plot" even the right command? I'd argue (not
> > having looked at the implementation) that we
> > should consider "splot", because splot naturally
> > deals with data on a rectangular grid (matrix data).
> 
> I'm not sure a rectangular grid is any type of requisite.  From the 
> documentation, it sounds like the parallelaxes is a means to visually 
> show correlation between disparate measurements.  That is, if there
> are strong color bands, I assume that is more correlation, be it
> positive or negative.
> 

Yes, it is a prereq. The idea is that you have a 
number of records, with each record having multiple
measurements. It is a safe (but not guaranteed)
assumption that each record has the same number
of measurements. (If this is not true, parallel
axis plots don't really apply - edge cases 
notwithstanding.)

> 
> > And that's exactly the type of data used for
> > parallel axes plots. Put another way: splot
> > already handles dynamic rows AND columns.
> 
> It actually may be its own type of plot, neither "plot" nor "splot". 

Ok, point well taken. From looking at the way it
currently works, I assumed that there was a desire to 
"piggy-pack" parallel axis on existing infrastructure.
If so, then splot might be a better starting point.

But if that's not the guiding principle, then parallel
axis should not be treated as an isolated type, but 
merely as a special case of multidimensional plots in
general. At the very least, they should be able to handle
polar coordinates together with "parallel axes" ("star plots").

>  From what Ethan describes, I'm guessing that the data file is
> re-read once for each axis to get the column of data that is to
> appear on the axis.  In some sense it's a one-dimensional plot, isn't
> it?  That is, the data only appears on one axis only and it is simply
> that there are many axes.  So, some analogous terms might be:
> 
> plot   ->  plot2d
> splot  ->  plot3d
> paxis  ->  plot1d
> 
> We can think of plot2d being a subset of plot3d, with a viewing angle 
> that's orthographic.  We can think of plot1d as being a subset of 
> plot2d, again with a viewing angle that eliminates one of the 
> dimensions.  But parallel axes is some kind of new creature,
> basically connecting points across multiple plots.  In theory it
> could be done with 2d and 3d plots, but would be a mess to look at of
> course.  So, parallelaxis is more along the lines of "multiplot",
> isn't it?  Should it's syntax fall more along that lines?  E.g.,
> 
> set parallelaxis layout 7,1

I think this is going in a similar direction to what I
said earlier - treat it as its own beast, but more 
generally. The idea of hitching onto the "multiplot"
features strikes me as interesting. That might deliver
the "star plot" application for (almost) free, by the way.

> 
> Dan

Re: with parallelaxes dumps core

[Daniel J S. <dan...@ie...>]

On 01/27/2015 10:25 AM, Philipp K. Janert wrote:
> On Tue, 27 Jan 2015 03:06:16 -0600
> Daniel J Sebald<dan...@ie...>  wrote:
>
>> On 01/26/2015 10:38 PM, sfeam wrote:
>>> On Monday, 26 January 2015 07:28:19 PM Philipp K. Janert wrote:
>>>>
>>>> The new plot style "with parallelaxes"
>>>> is cute. Unfortunately, it also dumps
>>>> core - whenever there are more than 7
>>>> columns to plot.
>>>
>>> The maximum is set at compile time, but
>>> yes the default is 7.
>>>
>
> Daniel -
>
> Thanks for looking into this!
>
> One comment, though: before going down this
> path (of extending the permissible number of
> cols in "using") very far, let's consider
> whether this is the right way to do it.
>
> Already, entering 7 explicit col numbers is a
> pain. Entering 35 (or whatever) different ones
> is simply not practical.

Well, as with binary data, it could be that the data file and the 
command itself are constructed by automation, i.e., a computer program 
or script.  Plus, it isn't that difficult to build up a long command in 
an input file using an editor.


> Should the whole approach be rethought? Is
> "plot" even the right command? I'd argue (not
> having looked at the implementation) that we
> should consider "splot", because splot naturally
> deals with data on a rectangular grid (matrix data).

I'm not sure a rectangular grid is any type of requisite.  From the 
documentation, it sounds like the parallelaxes is a means to visually 
show correlation between disparate measurements.  That is, if there are 
strong color bands, I assume that is more correlation, be it positive or 
negative.


> And that's exactly the type of data used for
> parallel axes plots. Put another way: splot
> already handles dynamic rows AND columns.

It actually may be its own type of plot, neither "plot" nor "splot". 
 From what Ethan describes, I'm guessing that the data file is re-read 
once for each axis to get the column of data that is to appear on the 
axis.  In some sense it's a one-dimensional plot, isn't it?  That is, 
the data only appears on one axis only and it is simply that there are 
many axes.  So, some analogous terms might be:

plot   ->  plot2d
splot  ->  plot3d
paxis  ->  plot1d

We can think of plot2d being a subset of plot3d, with a viewing angle 
that's orthographic.  We can think of plot1d as being a subset of 
plot2d, again with a viewing angle that eliminates one of the 
dimensions.  But parallel axes is some kind of new creature, basically 
connecting points across multiple plots.  In theory it could be done 
with 2d and 3d plots, but would be a mess to look at of course.  So, 
parallelaxis is more along the lines of "multiplot", isn't it?  Should 
it's syntax fall more along that lines?  E.g.,

set parallelaxis layout 7,1

Dan

Re: with parallelaxes dumps core

[sfeam <sf...@us...>]

On Tuesday, 27 January 2015 03:06:16 AM Daniel J Sebald wrote:
> On 01/26/2015 10:38 PM, sfeam wrote:
> > On Monday, 26 January 2015 07:28:19 PM Philipp K. Janert wrote:
> >>
> >> The new plot style "with parallelaxes"
> >> is cute. Unfortunately, it also dumps
> >> core - whenever there are more than 7
> >> columns to plot.
> >
> > The maximum is set at compile time, but
> > yes the default is 7.
> >
> >> 1) This limitation is not mentioned in
> >> the doc. (As far as I can see.)
> >
> > I thought it was, but now I can't find it either.
> > That is an oversight.
> >
> >> 2) Dumping core unconditionally is not
> >> a good user experience. It would be
> >> better to detect and reject the illegal
> >> input and warn the user.
> >
> > Indeed.
> >
> >> 3) The limitation to 7 cols (which, I
> >> suspect, depends on limitations in the
> >> way "using" is parsed) puts the entire
> >> plot style into question. The whole
> >> point of parallelaxes plots (to the
> >> degree they HAVE a point) is to deal
> >> with high-dim data, easily exceeding 7.
> >
> > If you have such a use-case, go ahead and file a
> > feature request.  It should not be too hard to make
> > the axis structures dynamic rather than static.
> > The original request for this feature provided examples
> > from the literature but none of them had even as many
> > as 7 axes in a single plot.  So that seemed
> > adequate as a default.  Failing to check for more
> > columns of input than expected is purely a bug.
> 
> Here's the hunk of code from datafile.c that you are referring to:
> 
> 	    /* check we have room for at least 7 columns */
> 	    if (df_max_cols < 7)
> 		expand_df_column(7);
> 
> 	    df_no_cols = sscanf(line, df_format,
> 				&df_column[0].datum,
> 				&df_column[1].datum,
> 				&df_column[2].datum,
> 				&df_column[3].datum,
> 				&df_column[4].datum,
> 				&df_column[5].datum,
> 				&df_column[6].datum);


Not correct.
That code path applies _only_ to the command
   plot <foo> using 1:2:... "format-for-using-statement"
where an explicit format is provided.

> and I'm trying to recall how the internal storage of data points works. 
>   If I'm remembering correctly, there is some type of limitation on the 
> number of elements of a data point, e.g., x, y, x tolerance, y 
> tolerance, z (or color), etc. owing to the use of a structure to store 
> the data.  Was the size of the structure up to seven elements, therefore 
> it was generally thought that only up to seven columns of a data file 
> line would be used?  Is this parallel axes plot using the same limitation?

Not relevant.
The data for parallel axis plots is allocated dynamically,
one array per axis.

	Ethan

Re: with parallelaxes dumps core

[Philipp K. J. <ja...@ie...>]

On Tue, 27 Jan 2015 03:06:16 -0600
Daniel J Sebald <dan...@ie...> wrote:

> On 01/26/2015 10:38 PM, sfeam wrote:
> > On Monday, 26 January 2015 07:28:19 PM Philipp K. Janert wrote:
> >>
> >> The new plot style "with parallelaxes"
> >> is cute. Unfortunately, it also dumps
> >> core - whenever there are more than 7
> >> columns to plot.
> >
> > The maximum is set at compile time, but
> > yes the default is 7.
> >

Daniel -

Thanks for looking into this!

One comment, though: before going down this
path (of extending the permissible number of
cols in "using") very far, let's consider 
whether this is the right way to do it.

Already, entering 7 explicit col numbers is a
pain. Entering 35 (or whatever) different ones 
is simply not practical.

Should the whole approach be rethought? Is 
"plot" even the right command? I'd argue (not
having looked at the implementation) that we
should consider "splot", because splot naturally
deals with data on a rectangular grid (matrix data).
And that's exactly the type of data used for 
parallel axes plots. Put another way: splot 
already handles dynamic rows AND columns. 

I'll toss in one more thought: whatever solution
is devised, it must contain decent support for
highlighting of individual records and groups of
records. Parallel axes are simply not useful without 
that - and an implementation that does not support 
this action is little more than a demo.

Best,

		Ph.


> 
> Here's the hunk of code from datafile.c that you are referring to:
> 
> 	    /* check we have room for at least 7 columns */
> 	    if (df_max_cols < 7)
> 		expand_df_column(7);
> 
> 	    df_no_cols = sscanf(line, df_format,
> 				&df_column[0].datum,
> 				&df_column[1].datum,
> 				&df_column[2].datum,
> 				&df_column[3].datum,
> 				&df_column[4].datum,
> 				&df_column[5].datum,
> 				&df_column[6].datum);
> 
> and I'm trying to recall how the internal storage of data points
> works. If I'm remembering correctly, there is some type of limitation
> on the number of elements of a data point, e.g., x, y, x tolerance, y 
> tolerance, z (or color), etc. owing to the use of a structure to
> store the data.  Was the size of the structure up to seven elements,
> therefore it was generally thought that only up to seven columns of a
> data file line would be used?  Is this parallel axes plot using the
> same limitation?
> 
> I'm for allowing more than seven columns (note a recursive use of
> sscanf seems required), but at the same time internal memory storage
> should be adjustable too--a much bigger project.  That is, for large
> data sets like images, having seven elements for each point could use
> a lot more memory than necessary.
> 
> Dan
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media,
> is your hub for all things parallel software development, from weekly
> thought leadership blogs to news, videos, case studies, tutorials and
> more. Take a look and join the conversation now.
> http://goparallel.sourceforge.net/
> _______________________________________________ gnuplot-beta mailing
> list gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Make Gnuplot using the mathematical minus sign

[Maurizio T. <mau...@ou...>]

Hi to everybody,

  Yesterday I posted a question on StackOverflow about the possibility to
use the mathematical minus sign for negative numbers for tick labels in
Gnuplot instead of the hyphen. (This is a request I got from the referee of
a paper I've just submitted.)

Although I have never hacked Gnuplot, I am fluent with C/C++ and would like
to try to write a patch that implements this feature. I would like to ask
you which would be the best way to do this:

1. Implement a pair of commands ("set hyphenminus" / "unset hyphenminus") 
which change this setting globally, i.e., on the X/Y/X2/Y2 axes.

2. Implement a new formatting sequence, like "%h", which takes care of using
the correct character.

My preference goes to the first option (if one cares for typographical
correctness, chances are that it wants it on every axis.). Moreover, I would
like to make the mathematical minus the default, and leave the possibility
to use the hyphen only as a way to retain backwards compatibility (this is
what Matplotlib does).

What do you think? Do you have suggestions about how to properly code this?

  Maurizio.

Re: with parallelaxes dumps core

[Daniel J S. <dan...@ie...>]

On 01/26/2015 10:38 PM, sfeam wrote:
> On Monday, 26 January 2015 07:28:19 PM Philipp K. Janert wrote:
>>
>> The new plot style "with parallelaxes"
>> is cute. Unfortunately, it also dumps
>> core - whenever there are more than 7
>> columns to plot.
>
> The maximum is set at compile time, but
> yes the default is 7.
>
>> 1) This limitation is not mentioned in
>> the doc. (As far as I can see.)
>
> I thought it was, but now I can't find it either.
> That is an oversight.
>
>> 2) Dumping core unconditionally is not
>> a good user experience. It would be
>> better to detect and reject the illegal
>> input and warn the user.
>
> Indeed.
>
>> 3) The limitation to 7 cols (which, I
>> suspect, depends on limitations in the
>> way "using" is parsed) puts the entire
>> plot style into question. The whole
>> point of parallelaxes plots (to the
>> degree they HAVE a point) is to deal
>> with high-dim data, easily exceeding 7.
>
> If you have such a use-case, go ahead and file a
> feature request.  It should not be too hard to make
> the axis structures dynamic rather than static.
> The original request for this feature provided examples
> from the literature but none of them had even as many
> as 7 axes in a single plot.  So that seemed
> adequate as a default.  Failing to check for more
> columns of input than expected is purely a bug.

Here's the hunk of code from datafile.c that you are referring to:

	    /* check we have room for at least 7 columns */
	    if (df_max_cols < 7)
		expand_df_column(7);

	    df_no_cols = sscanf(line, df_format,
				&df_column[0].datum,
				&df_column[1].datum,
				&df_column[2].datum,
				&df_column[3].datum,
				&df_column[4].datum,
				&df_column[5].datum,
				&df_column[6].datum);

and I'm trying to recall how the internal storage of data points works. 
  If I'm remembering correctly, there is some type of limitation on the 
number of elements of a data point, e.g., x, y, x tolerance, y 
tolerance, z (or color), etc. owing to the use of a structure to store 
the data.  Was the size of the structure up to seven elements, therefore 
it was generally thought that only up to seven columns of a data file 
line would be used?  Is this parallel axes plot using the same limitation?

I'm for allowing more than seven columns (note a recursive use of sscanf 
seems required), but at the same time internal memory storage should be 
adjustable too--a much bigger project.  That is, for large data sets 
like images, having seven elements for each point could use a lot more 
memory than necessary.

Dan

Re: with parallelaxes dumps core

[Philipp K. J. <ja...@ie...>]

[snip]

> 
> If you have such a use-case, go ahead and file a
> feature request.  It should not be too hard to make
> the axis structures dynamic rather than static.
> The original request for this feature provided examples
> from the literature but none of them had even as many
> as 7 axes in a single plot.  So that seemed
> adequate as a default.  Failing to check for more
> columns of input than expected is purely a bug.

Yes, it should definitely be dynamic - and
the question is whether there is a better 
way of doing it than having to enter all
cols explicitly. 

Regarding "references": my book (1st ed)
contains an example with 9 columns... 
Unwin's book "Graphics of Large Datasets"
shows one w/ 20 cols (p153). It's a moot
point, anyway, because an arbitrary limitation 
of cols is counter to the spirit of this method. 
(For practical reasons one may want to limit it, 
but at a high number - 150 or so.)

[snip]

> > 
> > There is one other thing: for practical 
> > purposes, the ability to highlight a 
> > single record (or group of records) in
> > a parallel axis plot is really, really
> > important (obviously the best way is 
> > with the mouse). I tried to plot only
> > a selected record via "every", but with
> > a strange results: when selecting a single
> > record (ev 170::170::) I get NO graph -
> > just an empty canvas. (No warning either.)

Did you see this, too? Both the need to 
highlight records, and the odd behavior
with "every"?

Re: with parallelaxes dumps core

[sfeam <sf...@us...>]

On Monday, 26 January 2015 07:28:19 PM Philipp K. Janert wrote:
> 
> The new plot style "with parallelaxes"
> is cute. Unfortunately, it also dumps
> core - whenever there are more than 7
> columns to plot.

The maximum is set at compile time, but
yes the default is 7.  

> 1) This limitation is not mentioned in
> the doc. (As far as I can see.)

I thought it was, but now I can't find it either.
That is an oversight.

> 2) Dumping core unconditionally is not 
> a good user experience. It would be
> better to detect and reject the illegal
> input and warn the user.

Indeed.

> 3) The limitation to 7 cols (which, I
> suspect, depends on limitations in the
> way "using" is parsed) puts the entire
> plot style into question. The whole 
> point of parallelaxes plots (to the 
> degree they HAVE a point) is to deal 
> with high-dim data, easily exceeding 7.

If you have such a use-case, go ahead and file a
feature request.  It should not be too hard to make
the axis structures dynamic rather than static.
The original request for this feature provided examples
from the literature but none of them had even as many
as 7 axes in a single plot.  So that seemed
adequate as a default.  Failing to check for more
columns of input than expected is purely a bug.

	Ethan

> I like this feature, in principle, but
> I am afraid the limitation to 7 columns
> really gets in the way.
> 
> There is one other thing: for practical 
> purposes, the ability to highlight a 
> single record (or group of records) in
> a parallel axis plot is really, really
> important (obviously the best way is 
> with the mouse). I tried to plot only
> a selected record via "every", but with
> a strange results: when selecting a single
> record (ev 170::170::) I get NO graph -
> just an empty canvas. (No warning either.)
> 
> Best,
> 
> 		Ph.
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

with parallelaxes dumps core

[Philipp K. J. <ja...@ie...>]

The new plot style "with parallelaxes"
is cute. Unfortunately, it also dumps
core - whenever there are more than 7
columns to plot.

1) This limitation is not mentioned in
the doc. (As far as I can see.)

2) Dumping core unconditionally is not 
a good user experience. It would be
better to detect and reject the illegal
input and warn the user.

3) The limitation to 7 cols (which, I
suspect, depends on limitations in the
way "using" is parsed) puts the entire
plot style into question. The whole 
point of parallelaxes plots (to the 
degree they HAVE a point) is to deal 
with high-dim data, easily exceeding 7.

I like this feature, in principle, but
I am afraid the limitation to 7 columns
really gets in the way.

There is one other thing: for practical 
purposes, the ability to highlight a 
single record (or group of records) in
a parallel axis plot is really, really
important (obviously the best way is 
with the mouse). I tried to plot only
a selected record via "every", but with
a strange results: when selecting a single
record (ev 170::170::) I get NO graph -
just an empty canvas. (No warning either.)

Best,

		Ph.

Re: Three small bugs with splot

[Philipp K. J. <ja...@ie...>]

On Mon, 26 Jan 2015 17:51:49 -0800
sfeam <sf...@us...> wrote:

> On Sunday, 25 January 2015 07:57:39 PM Philipp K. Janert wrote:
> > 
> > 1) The inline nohidden3d seems to have no effect
> > 
> > 	set isosamples 30; set hidden3d
> > 	splot exp(-(x**2+y**2)), 0.5 nohidden3d
> > 
> > The plane should be transparent; it isn't.
> 
> The documentation says:
> 
>   As of gnuplot version 4.6, hidden3d also affects 3D plotting styles
> `points`, `labels`, `vectors`, and `impulses` even if no surface is
> present in the graph. Unobscured portions of each vector are drawn as
> line segments (no arrowheads). Individual plots within the graph may
> be explicitly excluded from this processing by appending the extra
> option `nohidden3d` to the `with` specifier.
> 
> This may be insufficiently explicit, but the intended meaning is that
> the plot styles {points|labels|vectors|impulses} are now subject to
> hidden3d by default but can be exempted using the "nohidden3d"
> keyword. This keyword does not affect plot styles other than these
> four, and in particular it makes no sense to try to exclude actual
> surfaces from the surface processing.

Ok, that was indeed not clear to me. 
Might be worth restating in the doc that
inline "nohidden3d" only applies to those 
styles.

Re: Three small bugs with splot

[sfeam <sf...@us...>]

On Sunday, 25 January 2015 07:57:39 PM Philipp K. Janert wrote:
> 
> 1) The inline nohidden3d seems to have no effect
> 
> 	set isosamples 30; set hidden3d
> 	splot exp(-(x**2+y**2)), 0.5 nohidden3d
> 
> The plane should be transparent; it isn't.

The documentation says:

  As of gnuplot version 4.6, hidden3d also affects 3D plotting styles `points`,
  `labels`, `vectors`, and `impulses` even if no surface is present in the graph.
  Unobscured portions of each vector are drawn as line segments (no arrowheads).
  Individual plots within the graph may be explicitly excluded from this
  processing by appending the extra option `nohidden3d` to the `with` specifier.

This may be insufficiently explicit, but the intended meaning is that the
plot styles {points|labels|vectors|impulses} are now subject to hidden3d
by default but can be exempted using the "nohidden3d" keyword.
This keyword does not affect plot styles other than these four, and in
particular it makes no sense to try to exclude actual surfaces from the surface
processing.

Transparency is a whole other question.  

	Ethan

Re: Three small bugs with splot

[Daniel J S. <dan...@ie...>]

On 01/26/2015 01:24 PM, Philipp K. Janert wrote:
> On Mon, 26 Jan 2015 10:50 -0800
> Ethan A Merritt<sf...@us...>  wrote:
>
>> On Sunday, 25 January, 2015 22:38:53 Philipp K. Janert wrote:
>>> On Sun, 25 Jan 2015 21:46:11 -0800
>>> sfeam<sf...@us...>  wrote:
>>>
>>>> On Sunday, 25 January 2015 07:57:39 PM Philipp K. Janert wrote:
>>>>
>>>>> 3) set ticscale vs set xyplane with save command
>>>>>
>>>>> The "set ticscale" option is deprecated in favor of
>>>>> "set xyplane". However, upon "save", gnuplot saves
>>>>> only a "set ticscale" entry to the command file, not
>>>>> a "set xyscale" entry. It works, but it is confusing.
>>>>
>>>> "set ticscale" controls the length of the axis tic marks.
>>>> It has no connection to "set xyplane".
>>>
>>> My bad. I meant: "set ticslevel" (not "ticscale").
>>>
>>> "save" does not write "set xyplane" to file,
>>> it write out "set ticslevel". Which is deprecated.
>>
>> Are you sure?
>
> Yes, positive. That's with the gp5.0 release.
>
> set xyplane 10
> plot sin(x)
> save "ticken"
>
> fgrep "ticsl" ticken
> set ticslevel 10
>
> fgrep "xypl" ticken
> (not found)
>
> BUT:
>
> set xyplane at 10
> plot sin(x)
> save "tocken"
>
> fgrep "xypl" tocken
> set xyplane at 10
>
> fgrep "ticsl" tocken
> (not found)
>
> So, in other words, it works with
> 	set xyplane at ...
> but not with
> 	set xyplane ...
>
> Moreover, the default setting is set xyplane ...,
> which means that, by default, gnuplot writes out
> set ticslevel, not set xyplane.

Oh, I see.  gnuplot is treating "xyplane" as if it is the deprecated 
syntax.  That is,

set ticslevel #

is being substituted for non-"at" variation

set xyplane #

when it should be the other way around.

Dan

Re: Three small bugs with splot

[Philipp K. J. <ja...@ie...>]

On Mon, 26 Jan 2015 10:50 -0800
Ethan A Merritt <sf...@us...> wrote:

> On Sunday, 25 January, 2015 22:38:53 Philipp K. Janert wrote:
> > On Sun, 25 Jan 2015 21:46:11 -0800
> > sfeam <sf...@us...> wrote:
> > 
> > > On Sunday, 25 January 2015 07:57:39 PM Philipp K. Janert wrote:
> > > 
> > > > 3) set ticscale vs set xyplane with save command
> > > > 
> > > > The "set ticscale" option is deprecated in favor of
> > > > "set xyplane". However, upon "save", gnuplot saves
> > > > only a "set ticscale" entry to the command file, not
> > > > a "set xyscale" entry. It works, but it is confusing.
> > > 
> > > "set ticscale" controls the length of the axis tic marks.
> > > It has no connection to "set xyplane".
> > 
> > My bad. I meant: "set ticslevel" (not "ticscale").
> > 
> > "save" does not write "set xyplane" to file,
> > it write out "set ticslevel". Which is deprecated.
> 
> Are you sure?

Yes, positive. That's with the gp5.0 release.

set xyplane 10
plot sin(x)
save "ticken"

fgrep "ticsl" ticken
set ticslevel 10

fgrep "xypl" ticken
(not found)

BUT:

set xyplane at 10
plot sin(x)
save "tocken"

fgrep "xypl" tocken
set xyplane at 10

fgrep "ticsl" tocken
(not found)

So, in other words, it works with 
	set xyplane at ...
but not with 
	set xyplane ...

Moreover, the default setting is set xyplane ...,
which means that, by default, gnuplot writes out
set ticslevel, not set xyplane.

> 
> That's not what I see here:
> 
> gnuplot> set xyplane at z = -.123
> gnuplot> save 'foo'
> gnuplot> !grep xyplane foo
> set xyplane at -0.123
> gnuplot> !grep ticslevel foo
> gnuplot>
> 
> 	Ethan

Re: Three small bugs with splot

[Daniel J S. <dan...@ie...>]

On 01/26/2015 12:50 PM, Ethan A Merritt wrote:
> On Sunday, 25 January, 2015 22:38:53 Philipp K. Janert wrote:
>
>>  On Sun, 25 Jan 2015 21:46:11 -0800
>
>>  sfeam <sf...@us...> wrote:
>
>>
>
>>  > On Sunday, 25 January 2015 07:57:39 PM Philipp K. Janert wrote:
>
>>  >
>
>>  > > 3) set ticscale vs set xyplane with save command
>
>>  > >
>
>>  > > The "set ticscale" option is deprecated in favor of
>
>>  > > "set xyplane". However, upon "save", gnuplot saves
>
>>  > > only a "set ticscale" entry to the command file, not
>
>>  > > a "set xyscale" entry. It works, but it is confusing.
>
>>  >
>
>>  > "set ticscale" controls the length of the axis tic marks.
>
>>  > It has no connection to "set xyplane".
>
>>
>
>>  My bad. I meant: "set ticslevel" (not "ticscale").
>
>>
>
>>  "save" does not write "set xyplane" to file,
>
>>  it write out "set ticslevel". Which is deprecated.
>
> Are you sure?
>
> That's not what I see here:
>
> gnuplot> set xyplane at z = -.123
>
> gnuplot> save 'foo'
>
> gnuplot> !grep xyplane foo
>
> set xyplane at -0.123
>
> gnuplot> !grep ticslevel foo

Same here.  However, "ticslevel" is still saved.  E.g.,

gnuplot> set ticslevel -1
gnuplot> save 'foo'
gnuplot> !grep ticslevel foo
set ticslevel -1

If ticslevel is deprecated, then probably the equivalent "set xyplane 
relative <frac>" should be saved.

I suppose the easiest way to do this is to have a preprocess-type of 
step that replaces "set ticslevel <frac>" by the equivalent.  That way 
the command goes into the history queue with the right format.  Easier 
said than done, I guess, considering that gnuplot has word completion, e.g.,

gnuplot> se ticsl -1

is acceptable.

Dan

Re: Three small bugs with splot

[Ethan A M. <sf...@us...>]

On Sunday, 25 January, 2015 22:38:53 Philipp K. Janert wrote:
> On Sun, 25 Jan 2015 21:46:11 -0800
> sfeam <sf...@us...> wrote:
> 
> > On Sunday, 25 January 2015 07:57:39 PM Philipp K. Janert wrote:
> > 
> > > 3) set ticscale vs set xyplane with save command
> > > 
> > > The "set ticscale" option is deprecated in favor of
> > > "set xyplane". However, upon "save", gnuplot saves
> > > only a "set ticscale" entry to the command file, not
> > > a "set xyscale" entry. It works, but it is confusing.
> > 
> > "set ticscale" controls the length of the axis tic marks.
> > It has no connection to "set xyplane".
> 
> My bad. I meant: "set ticslevel" (not "ticscale").
> 
> "save" does not write "set xyplane" to file,
> it write out "set ticslevel". Which is deprecated.

Are you sure?

That's not what I see here:

gnuplot> set xyplane at z = -.123
gnuplot> save 'foo'
gnuplot> !grep xyplane foo
set xyplane at -0.123
gnuplot> !grep ticslevel foo
gnuplot>

	Ethan

Re: Three small bugs with splot

[Philipp K. J. <ja...@ie...>]

On Sun, 25 Jan 2015 21:46:11 -0800
sfeam <sf...@us...> wrote:

> On Sunday, 25 January 2015 07:57:39 PM Philipp K. Janert wrote:
> 
> > 3) set ticscale vs set xyplane with save command
> > 
> > The "set ticscale" option is deprecated in favor of
> > "set xyplane". However, upon "save", gnuplot saves
> > only a "set ticscale" entry to the command file, not
> > a "set xyscale" entry. It works, but it is confusing.
> 
> "set ticscale" controls the length of the axis tic marks.
> It has no connection to "set xyplane".

My bad. I meant: "set ticslevel" (not "ticscale").

"save" does not write "set xyplane" to file,
it write out "set ticslevel". Which is deprecated.

> 
> 	Ethan
> 
> 

Re: Three small bugs with splot

[sfeam <sf...@us...>]

On Sunday, 25 January 2015 07:57:39 PM Philipp K. Janert wrote:

> 3) set ticscale vs set xyplane with save command
> 
> The "set ticscale" option is deprecated in favor of
> "set xyplane". However, upon "save", gnuplot saves
> only a "set ticscale" entry to the command file, not
> a "set xyscale" entry. It works, but it is confusing.

"set ticscale" controls the length of the axis tic marks.
It has no connection to "set xyplane".

	Ethan

Three small bugs with splot

[Philipp K. J. <ja...@ie...>]

1) The inline nohidden3d seems to have no effect

	set isosamples 30; set hidden3d
	splot exp(-(x**2+y**2)), 0.5 nohidden3d

The plane should be transparent; it isn't.


2) Line types in key off by one in contour plots with hidden3d

	set isosamples 30; set hidden3d
	set contour both
	splot [-2:2][-2:2] exp(-(x**2+y**2))

If you look closely, you realize that the colors of the
linesamples in the key are off by one, because the color
that's used for the underside of the surface is not taken
into account. If you do

	set hidden3d offset 0

then everything is fine (but the underside of the surface
is the same color as the top).


3) set ticscale vs set xyplane with save command

The "set ticscale" option is deprecated in favor of
"set xyplane". However, upon "save", gnuplot saves
only a "set ticscale" entry to the command file, not
a "set xyscale" entry. It works, but it is confusing.

Best,

		Ph.

[Slightly OT] Gnuplot in Action: Second Edition

[Philipp K. J. <ja...@ie...>]

Gnuplot 5 was released earlier this year.

I am taking this opportunity to update my 
book "Gnuplot in Action". The second edition
will be completely revised to reflect the
new features of Gnuplot 5, but it will also
include many other improvements and learnings
that have come up since the first edition.

A preview version of the first few chapters
is now available from the publisher:
	http://www.manning.com/janert2

This is a good time to make suggestions for the
new edition, and also to point out typos or errors 
in the first edition. Please email me directly, or 
post your comments to the book's forum:
	https://forums.manning.com/forums/gnuplot-in-action-second-edition

The publisher is giving out a limited number
of preview copies - if you are interested,
contact me or the publisher.

The final book is expected later this year.

Best,

		Ph.

Re: GP5: Three small bugs (in dusty corners)

[Philipp K. J. <ja...@ie...>]

On Fri, 16 Jan 2015 22:00:27 -0800
sfeam <sf...@us...> wrote:

> On Wednesday, 07 January 2015 04:08:50 PM Philipp K. Janert wrote:
> > 
> > I seem to have observed three minor bugs in gp5:
> > 
> > 
> > 1) Filledcurve above/below
> > [snip]
> > 2) Enhanced text, key, and cairo
> > [snip]
> > 3) set xmtics, save, load
> > [snip]
> 
> These are now fixed.

Awesome! ;-)

Re: GP5: Three small bugs (in dusty corners)

[sfeam <sf...@us...>]

On Wednesday, 07 January 2015 04:08:50 PM Philipp K. Janert wrote:
> 
> I seem to have observed three minor bugs in gp5:
> 
> 
> 1) Filledcurve above/below
> [snip]
> 2) Enhanced text, key, and cairo
> [snip]
> 3) set xmtics, save, load
> [snip]

These are now fixed.

	Ethan