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

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

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

On Thursday, 15 January, 2015 22:13:14 Jun T. wrote:
> 
> On 2015/01/09, at 10:36, 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:
> >> 
> >> 2) Enhanced text, key, and cairo
> > 
> > That odd, because wxt _is_ one of the cairo terminals.
> 
> 
> (I know a patch is already in CVS)
> 
> In cairotrm_put_text(), enhanced_recursion() is used only if the string
> contains mark-up characters "{}^_@&~"; otherwise gp_cairo_draw_text() is used.
> [snip] 
> In wxt_put_text() (wxt_gui.cpp), on the other hand, enhanced_recursion()
> is used always; thus wxt does not have this problem.

Thank you. Yes, that indeed explains the difference.

	Ethan

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

[Jun T. <tak...@kb...>]

On 2015/01/09, at 10:36, 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:
>> 
>> 2) Enhanced text, key, and cairo
> 
> That odd, because wxt _is_ one of the cairo terminals.


(I know a patch is already in CVS)

In cairotrm_put_text(), enhanced_recursion() is used only if the string
contains mark-up characters "{}^_@&~"; otherwise gp_cairo_draw_text() is used.

When drawing "{/:Bold Hello}",
enhanced_recursion() calls gp_cairo_enhanced_open(),
which calls gp_cairo_set_font(),
which sets plot->fontweight (gp_cairo.cpp:line 324):

  plot->fontweight = PANGO_WEIGHT_BOLD;

But this fontweight is not reset to the original value after drawing
the string.

When drawing "World",
gp_cairo_draw_text() uses the plot->fontweight (gp_cairo.cpp:line 867),
which still has the value PANGO_WEIGHT_BOLD:

  pango_font_description_set_weight (desc, plot->fontweight);


In wxt_put_text() (wxt_gui.cpp), on the other hand, enhanced_recursion()
is used always; thus wxt does not have this problem.


Jun

Re: Gnuplot version 5.0 is now available

[Achim G. <Str...@Ne...>]

Achim Gratz <Stromeko <at> nexgo.de> writes:
> Other than that things seem to work well although we'll have to change a
> number of scripts that got caught in the changes w.r.t. to the linetype
> command and some tightened syntax rules.  On the upside it looks we can
> drop a patch that gave us more linetypes and dash patterns and just
> define them in the defaults instead.

We've adapted the scripts now.

It was mostly that in many places an "offset" is now required instead of
simply the two coordinates.

Some observations that need further investigation ("before" refers to
gnuplot 4.6.6 and we're using the cairopdf terminal unless otherwise noted):

The linetype -1 is no longer working as it did before at least when you try
to change the linewidth and/or the dash type.

The positioning of the plot area is different than before.  There's more
space below the title than there was before and less space below the plot
area if you have the legend below the plot.

The ticks and grid lines are much thicker than before.

The Cairo PDF output is about 50% larger than before.  Going through PS and
ghostscript doesn't produce noticeably larger files.


Regards,
Achim.

Re: Please discuss [Re: [PATCH] boxplot: fix tics placement]

[Jouke W. <j.w...@gm...>]

On Wed, Jan 7, 2015 at 2:02 AM, Ethan A Merritt
<sf...@us...> wrote:
> On Saturday, 03 January, 2015 12:39:14 Jouke Witteveen wrote:
>
>> The x-value of individual boxplots is ignored when placing tics for
>
>> multiple boxplots.
>
>>
>
>> This patch fixes that issue.
>
> [snip]
>
>
>
> Bug tracker item: https://sourceforge.net/p/gnuplot/bugs/1532/
>
>
>
> Example problem case adapted from the Bug Tracker
>
> (Example uses only a single point per boxplot)
>
>
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>
> $DATA << EOD
>
> 2 1
>
> 3 2
>
> 5 3
>
> EOD
>
>
>
> set style boxplot separation 0
>
> plot 'data' using 1:2:(0):(strcol(1)) with boxplot
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>
>
>
> There is a conflict between applying the first using spec (column 1)
>
> as a coordinate and applying the style parameter "separation".
>
>
>
> Currently the numeric column 1 values win for placing the
>
> boxplots themselves (a single point each in the example).
>
> So there are plots at x=2, x=3, and x=5.
>
>
>
> But the separation spec wins for placing the labels,
>
> which means the numeric values in column 1 are ignored and
>
> their string representations all placed as labels at x=2.
>
>
>
> Documentation:
>
> "The first and third columns (x coordinate and width) are normally
>
> provided as constants rather than as data columns."
>
>
>
> Question:
>
> Is it ever correct to provide a non-constant x coordinate as
>
> in the example? How would the program deal with a mismatch
>
> between the x-coordinate (column 1) and the "discrete levels of
>
> of factor variable" in column 4? That can't happen in the
>
> example above because the same data column is used for both
>
> but that wouldn't normally be true.
>
>
>
> In other words - is this really a bug?
>

There is a possible mismatch between the factor level (column 4) and
the width (column 3) too. The situation is far from pretty, but the
proposed patch in the bugreport adds to the usability without breaking
compatibility.

What are the gnuplot conventions regarding interface breakage? I'd say
a cleaner interface for boxplots would be a using spec where the first
column is the x-coordinate and the second the y-coordinate. Grouping
then takes place based on the x-coordinate and labeling can be
implemented via an additional xticlabels column, as is used in other
plot types already. The width still needs a solution. We could go with
a third column in the using spec, as is currently done, or with a user
specified function which takes an x coordinate as input and yields a
width. The latter approach would lead to unambiguous widths.

These are just some thoughts, nothing more.

Regards,
- Jouke

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:
> 
> 2) Enhanced text, key, and cairo
> 
> 	set key title "{/:Bold Hello}"
> 	plot sin(x) t "World"
> 
> I'd expect the title of the key to be bold,
> but the title entry for the curve to be 
> normal weight. That's also what it does in
> wxt, but for any of the cairo terminals, all
> key entries are bold.

That odd, because wxt _is_ one of the cairo terminals.

It seems the specific bug is that the final curly bracket in
the key title doesn't take effect if it is the last character
in the string.  The problem goes away if you add a blank,
or anything else, after the closing bracket.

That must be a big clue, but at the moment I don't 
see where it points.  Most of the code involved is
shared by all terminals, so why does the problem only
show up in a couple of them?

	Ethan

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

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

On Thu, 8 Jan 2015 13:56:29 +0100 (CET)
Petr Mikulik <mi...@ph...> wrote:

> > I seem to have observed three minor bugs in gp5:
> >
> > 1) Filledcurve above/below
> >
> > My understanding is that
> > 	plot sin(x) w filledc above y1=0
> > should fill only the area between y=0 and
> > the sine curve. What I observe is that it
> > does not fill at all. With
> > 	plot sin(x) w filledc below y1=0
> > gnuplot fills both above and below.
> >
> > The plot is sensitive to the value supplied,
> > but above/below do not seem to be interpreted
> > properly.
> 
> I see, the above/below keywords work correctly in 4.6 but not in 5.0.
> I think it was not spotted because fillcrvs.dem does not test them.

Interestingly, it works if the limiting line is 
provided as "data". This command works as advertised:

plot "+" u 1:(sin($1)):(0) w filledc above

> 
> ---
> PM

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

[Petr M. <mi...@ph...>]

> I seem to have observed three minor bugs in gp5:
>
> 1) Filledcurve above/below
>
> My understanding is that
> 	plot sin(x) w filledc above y1=0
> should fill only the area between y=0 and
> the sine curve. What I observe is that it
> does not fill at all. With
> 	plot sin(x) w filledc below y1=0
> gnuplot fills both above and below.
>
> The plot is sensitive to the value supplied,
> but above/below do not seem to be interpreted
> properly.

I see, the above/below keywords work correctly in 4.6 but not in 5.0.
I think it was not spotted because fillcrvs.dem does not test them.

---
PM

GP5: Three small bugs (in dusty corners)

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

I seem to have observed three minor bugs in gp5:


1) Filledcurve above/below

My understanding is that 
	plot sin(x) w filledc above y1=0
should fill only the area between y=0 and 
the sine curve. What I observe is that it
does not fill at all. With
	plot sin(x) w filledc below y1=0
gnuplot fills both above and below.

The plot is sensitive to the value supplied,
but above/below do not seem to be interpreted
properly.


2) Enhanced text, key, and cairo

	set key title "{/:Bold Hello}"
	plot sin(x) t "World"

I'd expect the title of the key to be bold,
but the title entry for the curve to be 
normal weight. That's also what it does in
wxt, but for any of the cairo terminals, all
key entries are bold.


3) set xmtics, save, load

(I agree, a truly dusty corner!)

	set xmtics
	plot "data" u 1:2 w l
	save "foobar.gp"
	load "foobar.gp"

This produces an error:

	set xmtics norangelimit
	unexpected or unrecognized token


No biggy all three, but I'd thought I'd point them 
out. Maybe worth a remark in the release notes.

Re: Strange behavior with "++"?

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

On Wednesday, 07 January, 2015 14:25:53 Philipp K. Janert wrote:
> 
> Consider the following commands:
> 
> set view map
> set isosamples 10
> splot [0:1][0:1] "++" u 1:2:(1) w p
> 
> I would have expected to get a graph
> of 10x10 points on a grid.
> 
> Instead, I get 10 horizontal lines of
> densely packed points.

I thought there had been a discussion of this on gnuplot-beta
with reference to whether it should be changed for version 5.
But now I can't seem to find it. Anyhow, it wasn't changed
and '++' acts just like any other input source to 3D sampling.
  
The x sampling is controlled by "set sample" (default = 100)
The y sampling is controlled by "set isosample" (default = 10)

It says exactly this in the documentation
gnuplot> help special-filenames
 [snip]
 Similarly the pseudo-file '++' returns 2 columns of data forming a regular
 grid of [x,y] coordinates with the number of points along x controlled by
 `set samples` and the number of points along y controlled by `set isosamples`.

 	Ethan


> 
> When I do this:
> 
> set view map
> set isosamples 10
> unset samples
> splot [0:1][0:1] "++" u 1:2:(1) w p
> 
> I get 10 horizontal lines of less
> densely packed points - but still
> no 10x10 grid.
> 
> Am I misunderstanding what "++" does,
> or is this a bug?
> 
> Best,
> 
> 		Ph.

Strange behavior with "++"?

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

Consider the following commands:

set view map
set isosamples 10
splot [0:1][0:1] "++" u 1:2:(1) w p

I would have expected to get a graph
of 10x10 points on a grid.

Instead, I get 10 horizontal lines of
densely packed points.

When I do this:

set view map
set isosamples 10
unset samples
splot [0:1][0:1] "++" u 1:2:(1) w p

I get 10 horizontal lines of less
densely packed points - but still
no 10x10 grid.

Am I misunderstanding what "++" does,
or is this a bug?

Best,

		Ph.

Re: Gnuplot version 5.0 is now available

[Enrico F. <fo...@ly...>]

On Tue, Jan 06, 2015 at 12:11:56PM -0800, Ethan A Merritt wrote:

> On Tuesday, 06 January, 2015 19:25:17 Achim Gratz wrote:
> > Ethan A Merritt writes:
> > > Gnuplot version 5.0 is now available.
> > 
> > Thanks.  I've compiled on Cygwin (with cygport/autotools and both on
> > 64bit and 32bit) and see the following issues:
> 
> Thanks for testing.
> 
> > 1. The Qt terminal still doesn't work.  No plot window ever shows up and
> > each invocation of plot will produce another qt_terminal process.
> > gnuplot itself seems to hang, but recovers after about 20s with a
> > message about "font initialisation" taking too long.
> 
> I'm afraid I have no insight into what might be causing that problem.
> IIRC the initial testers on OSX reported a similar problem but in
> that case it really was font initialisation and the problem went 
> away after the first run.

On Cygwin, this is due to the fact that non-blocking named pipes do not
work. See: http://thread.gmane.org/gmane.os.cygwin/113787/focus=114321

However, patching both Qt and gnuplot sources, I am able to get a
working Qt terminal on Cygwin. I am attaching the patches I use.

> > 3. The demo plugin doesn't link, I haven't yet investigated why
> > (probably some of the hardcoded linker flags don't make much sense on
> > Cygwin).  I didn't find a way to tell configure that it should not
> > compile the demo plugin other than removing the plugin support
> > completely.
> 
> ./configure --disable-plugins
> is supposed to work.  Does it not?

I found that replacing "so" with "dll" in demo/plugin/Makefile.am does
produce a plugin, even if it is named demo_plugin.dll.exe, i.e., with
an extra .exe suffix...

HTH

-- 
Enrico

Please discuss [Re: [PATCH] boxplot: fix tics placement]

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

On Saturday, 03 January, 2015 12:39:14 Jouke Witteveen wrote:
> The x-value of individual boxplots is ignored when placing tics for
> multiple boxplots.
> 
> This patch fixes that issue. 
 [snip]

Bug tracker item: https://sourceforge.net/p/gnuplot/bugs/1532/

Example problem case adapted from the Bug Tracker
(Example uses only a single point per boxplot)

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
$DATA << EOD
2   1
3   2
5   3
EOD

set style boxplot separation 0
plot 'data' using 1:2:(0):(strcol(1)) with boxplot
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

There is a conflict between applying the first using spec (column 1)
as a coordinate and applying the style parameter "separation".

Currently the numeric column 1 values win for placing the
boxplots themselves (a single point each in the example).
So there are plots at x=2, x=3, and x=5.

But the separation spec wins for placing the labels,
which means the numeric values in column 1 are ignored and
their string representations all placed as labels at x=2.

Documentation:
  "The first and third columns (x coordinate and width) are normally
   provided as constants rather than as data columns."

Question:
  Is it ever correct to provide a non-constant x coordinate as
  in the example?  How would the program deal with a mismatch
  between the x-coordinate (column 1) and the "discrete levels of
  of factor variable" in column 4?  That can't happen in the 
  example above because the same data column is used for both
  but that wouldn't normally be true.

In other words - is this really a bug?

Re: Gnuplot version 5.0 is now available

[Achim G. <Str...@ne...>]

Ethan A Merritt writes:
> Can you point to some documentation or policy about when that
> pkg-config field is relevant or necessary?

It's used in both Cygwin and openSUSE, but instead of looking at the .pc
file please try

pkg-config --variable=host_bins QT5Core

as there may be some fallback rules to fill in empty slots (I'm not
overly familiar with how the .pc files are put together).  If not, then
the configure rule in question should probably be re-written using the
PKG_CHECK_VAR autoconf macro to provide a fallback specific to gnuplot.

In any case using exec_prefix is clearly wrong (it works on some
installations purely by accident) and host_bins is what Qt5 introduced
as a repleacement for the tool variables in Qt4.

https://qt.gitorious.org/qt/qtbase/source/3fed060b94ff04131de603d4d668ae7853e50a53:dist/changes-5.0.0

--8<---------------cut here---------------start------------->8---
 * moc_dir, rcc_dir and some other tool variables are not defined in Qt's .pc files any more;
the generic host_bins is defined instead.
--8<---------------cut here---------------end--------------->8---

> ./configure --disable-plugins
> is supposed to work. Does it not?

Yes (I've been using that), but AFAICS that disables plugin support
completely.  I just wanted to find a way to not compile the demo plugin
until I can figure out why it doesn't link and there doesn't seem to be
any.

> If you don't mind my asking, who is the "we" in this case?

My colleagues and myself at work.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: Gnuplot version 5.0 is now available

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

On Tuesday, 06 January, 2015 19:25:17 Achim Gratz wrote:
> Ethan A Merritt writes:
> > Gnuplot version 5.0 is now available.
> 
> Thanks.  I've compiled on Cygwin (with cygport/autotools and both on
> 64bit and 32bit) and see the following issues:

Thanks for testing.

> 1. The Qt terminal still doesn't work.  No plot window ever shows up and
> each invocation of plot will produce another qt_terminal process.
> gnuplot itself seems to hang, but recovers after about 20s with a
> message about "font initialisation" taking too long.

I'm afraid I have no insight into what might be causing that problem.
IIRC the initial testers on OSX reported a similar problem but in
that case it really was font initialisation and the problem went 
away after the first run.

> 2. Configuring with Qt5 need changes to configure.in to work.  The
> configure script tries to determine the path to uic et.al. via a
> pkg-config query for exec_bin.  The correct variable to query is
> actually host_bins.

Hmm.
On my linux systems the host_bins field in Qt5Core.pc is empty,
so I am not sure this convention is universal.

On the other hand, the linux Qt5 package also sets the correct path via
/etc/profile.d/qt5.sh so that in practice the gnuplot autoconfigure
script would work anyhow.

Can you point to some documentation or policy about when that
pkg-config field is relevant or necessary?

> --8<---------------cut here---------------start------------->8---
>  QT5LOC=`$PKG_CONFIG --variable=exec_prefix Qt5Core`
>  UIC=${QT5LOC}/bin/uic
>  MOC=${QT5LOC}/bin/moc
>  RCC=${QT5LOC}/bin/rcc
>  LRELEASE=${QT5LOC}/bin/lrelease
> -------
>  QT5LOC=`$PKG_CONFIG --variable=host_bins Qt5Core`
>  UIC=${QT5LOC}/uic
>  MOC=${QT5LOC}/moc
>  RCC=${QT5LOC}/rcc
>  LRELEASE=${QT5LOC}/lrelease
> 
> --8<---------------cut here---------------end--------------->8---
> 
> 3. The demo plugin doesn't link, I haven't yet investigated why
> (probably some of the hardcoded linker flags don't make much sense on
> Cygwin).  I didn't find a way to tell configure that it should not
> compile the demo plugin other than removing the plugin support
> completely.

./configure --disable-plugins
is supposed to work.  Does it not?

> Other than that things seem to work well although we'll have to change a
> number of scripts that got caught in the changes w.r.t. to the linetype
> command and some tightened syntax rules.  On the upside it looks we can
> drop a patch that gave us more linetypes and dash patterns and just
> define them in the defaults instead.

If you don't mind my asking, who is the "we" in this case?

> 
> Regards,
> Achim.

	Ethan 

Re: Gnuplot version 5.0 is now available

[Achim G. <Str...@ne...>]

Ethan A Merritt writes:
> Gnuplot version 5.0 is now available.

Thanks.  I've compiled on Cygwin (with cygport/autotools and both on
64bit and 32bit) and see the following issues:

1. The Qt terminal still doesn't work.  No plot window ever shows up and
each invocation of plot will produce another qt_terminal process.
gnuplot itself seems to hang, but recovers after about 20s with a
message about "font initialisation" taking too long.

2. Configuring with Qt5 need changes to configure.in to work.  The
configure script tries to determine the path to uic et.al. via a
pkg-config query for exec_bin.  The correct variable to query is
actually host_bins.

--8<---------------cut here---------------start------------->8---
 QT5LOC=`$PKG_CONFIG --variable=exec_prefix Qt5Core`
 UIC=${QT5LOC}/bin/uic
 MOC=${QT5LOC}/bin/moc
 RCC=${QT5LOC}/bin/rcc
 LRELEASE=${QT5LOC}/bin/lrelease
-------
 QT5LOC=`$PKG_CONFIG --variable=host_bins Qt5Core`
 UIC=${QT5LOC}/uic
 MOC=${QT5LOC}/moc
 RCC=${QT5LOC}/rcc
 LRELEASE=${QT5LOC}/lrelease

--8<---------------cut here---------------end--------------->8---

3. The demo plugin doesn't link, I haven't yet investigated why
(probably some of the hardcoded linker flags don't make much sense on
Cygwin).  I didn't find a way to tell configure that it should not
compile the demo plugin other than removing the plugin support
completely.


Other than that things seem to work well although we'll have to change a
number of scripts that got caught in the changes w.r.t. to the linetype
command and some tightened syntax rules.  On the upside it looks we can
drop a patch that gave us more linetypes and dash patterns and just
define them in the defaults instead.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

Re: Gnuplot version 5.0 is now available

[Petr M. <mi...@ph...>]

> Gnuplot version 5.0 is now available.

Really great achievement!

I noticed a small bug - the "test" command on x11 shows dashed rectangle 
around the central numbers instead of a solid one.

I miss a note in "help new-features" why the linetype colour sequence has 
changed and how to revert it back. (The most strange is red at position 7.)
I remember the discussion about colour blind people but at the same time there 
are millions of old graphs rendered in the "traditional colour sequence" and 
most users are used to the first 3-4 colours.
Actually, "help linetype" says:
  ...
  For example, linetypes one and two default to red and green.
  ...
which is no longer valid.

---
Petr

Re: [PATCH] boxplot: introduce a default factor

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

On Saturday, 03 January 2015 06:25:29 PM sfeam wrote:
> On Saturday, 03 January 2015 12:35:27 PM Jouke Witteveen wrote:
> > When a row in the datafile contains no factor, its y-value is stored in
> > place of the factor identifier, leading to ambiguities.
> > If the datafile contains
> > 0	0	0	foo
> > 0	1
> > The second row will be marked as part of the 'foo' boxplot.
> > 
> > This patch fixes that issue.
> > ---
> > diff -Naur gnuplot-5.0.0.orig/src/gadgets.h gnuplot-5.0.0/src/gadgets.h
> > --- gnuplot-5.0.0.orig/src/gadgets.h	2015-01-02 22:06:25.488402227 +0100
> > +++ gnuplot-5.0.0/src/gadgets.h	2015-01-02 22:06:25.458403577 +0100
> > @@ -279,6 +279,8 @@
> >  	BOXPLOT_FACTOR_LABELS_X2
> >  } t_boxplot_factor_labels;
> >  
> > +#define DEFAULT_BOXPLOT_FACTOR -1
> > +
> >  typedef struct boxplot_style {
> >      int limit_type;	/* 0 = multiple of interquartile 1 = fraction of points */
> >      double limit_value;
> > diff -Naur gnuplot-5.0.0.orig/src/plot2d.c gnuplot-5.0.0/src/plot2d.c
> > --- gnuplot-5.0.0.orig/src/plot2d.c	2015-01-02 22:06:25.488402227 +0100
> > +++ gnuplot-5.0.0/src/plot2d.c	2015-01-02 22:08:57.411693594 +0100
> > @@ -910,19 +910,22 @@
> >  		store2d_point(current_plot, i++, v[0], v[1], v[0], v[0],
> >  			      v[1] - v[2], v[1] + v[2], -1.0);
> >  	    } else {
> > -		double w;
> > +		double ylow, w;
> >  		if (current_plot->plot_style == CANDLESTICKS
> >  		    || current_plot->plot_style == FINANCEBARS) {
> >  		    int_warn(storetoken, "This plot style does not work with 1 or 2 cols. Setting to points");
> >  		    current_plot->plot_style = POINTSTYLE;
> > -		}
> > +		} else if (current_plot->plot_style == BOXPLOT)
> > +		    ylow = DEFAULT_BOXPLOT_FACTOR;
> > +		else
> > +		    ylow = v[1];
> >  		if (current_plot->plot_smooth == SMOOTH_ACSPLINES)
> >  		    w = 1.0;	/* Unit weights */
> >  		else
> >  		    w = -1.0;	/* Auto-width boxes in some styles */
> >  		/* Set x/y high/low to exactly [x,y] */
> >  		store2d_point(current_plot, i++, v[0], v[1], 
> > -						 v[0], v[0], v[1], v[1], w);
> > +						 v[0], v[0], ylow, v[1], w);
> >  	    }
> >  	    break;
> >  
> > @@ -1004,7 +1007,7 @@
> >  
> >  		case BOXPLOT:	/* x, y, width */
> >  		    store2d_point(current_plot, i++, v[0], v[1], v[0]-v[2]/2., v[0]+v[2]/2.,
> > -		    		  v[1], v[1], v[2]);
> > +				  DEFAULT_BOXPLOT_FACTOR, v[1], v[2]);
> >  		    break;
> >  
> >  #ifdef EAM_OBJECTS
> > @@ -1513,7 +1516,7 @@
> >      /* This can happen if the user specifies a non-existent column:
> >       * fall back to single-boxplot mode */
> >      if (!string)
> > -	return 0;
> > +	return DEFAULT_BOXPLOT_FACTOR;
> >  
> >      /* Remove the trailing garbage, quotes etc. from the string */ 
> >      trimmed_string = df_parse_string_field(string);
> 
> Bug #2
> I agree there may be a bug here, but I can't reproduce exactly
> what you describe.  Could you please provide a full example with
> both the input and the command used to plot?
> 
> If I understand the problem case correctly, a missing column in 
> the input data is a failure in its own right and the point should 
> be discarded before ever reaching your new code.
> The actual result seems to depend on additional factors like 
> "set datafile separator". But in cases where the point is not 
> discarded I don't see it incorrectly added to some other category
>  - instead the plot contains an extra boxplot column with a blank
> label into which the problem points are placed. 
> That's arguably a correct result, although it's not what I expected.

I've applied this patch with 2 modifications.
1) It handles the case of the factor column being present but empty
   (e.g. in a *.csv file) as well as the case of the column being
   missing altogether.
2) The factor is now stored in the z/w/misc slot of the point structure
   rather than misusing ylow.  For the moment it is *also* stored in 
   ylow in the case of true 4-column input since that is expected by 
   the sorting and drawing routines.  But this can go away later, as
   shown by your patch #4.

Disregarding patch #3 for now since it addressing a slightly different
issue,  it would be nice if you would revise patch #4 so that it 
(1) does not refer to or use the changes in patch #3
(2) gets rid of all the y value mangling, which is no longer necessary.
Instead of temporarily replacing y with VERYLARGE / UNDEFINED so that
the point count can be based on y, simply step past any points for 
with the factor (now stored in z) doesn't match.

Re: [PATCH] boxplot: introduce a default factor

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

On Saturday, 03 January 2015 12:35:27 PM Jouke Witteveen wrote:
> When a row in the datafile contains no factor, its y-value is stored in
> place of the factor identifier, leading to ambiguities.
> If the datafile contains
> 0	0	0	foo
> 0	1
> The second row will be marked as part of the 'foo' boxplot.
> 
> This patch fixes that issue.
> ---
> diff -Naur gnuplot-5.0.0.orig/src/gadgets.h gnuplot-5.0.0/src/gadgets.h
> --- gnuplot-5.0.0.orig/src/gadgets.h	2015-01-02 22:06:25.488402227 +0100
> +++ gnuplot-5.0.0/src/gadgets.h	2015-01-02 22:06:25.458403577 +0100
> @@ -279,6 +279,8 @@
>  	BOXPLOT_FACTOR_LABELS_X2
>  } t_boxplot_factor_labels;
>  
> +#define DEFAULT_BOXPLOT_FACTOR -1
> +
>  typedef struct boxplot_style {
>      int limit_type;	/* 0 = multiple of interquartile 1 = fraction of points */
>      double limit_value;
> diff -Naur gnuplot-5.0.0.orig/src/plot2d.c gnuplot-5.0.0/src/plot2d.c
> --- gnuplot-5.0.0.orig/src/plot2d.c	2015-01-02 22:06:25.488402227 +0100
> +++ gnuplot-5.0.0/src/plot2d.c	2015-01-02 22:08:57.411693594 +0100
> @@ -910,19 +910,22 @@
>  		store2d_point(current_plot, i++, v[0], v[1], v[0], v[0],
>  			      v[1] - v[2], v[1] + v[2], -1.0);
>  	    } else {
> -		double w;
> +		double ylow, w;
>  		if (current_plot->plot_style == CANDLESTICKS
>  		    || current_plot->plot_style == FINANCEBARS) {
>  		    int_warn(storetoken, "This plot style does not work with 1 or 2 cols. Setting to points");
>  		    current_plot->plot_style = POINTSTYLE;
> -		}
> +		} else if (current_plot->plot_style == BOXPLOT)
> +		    ylow = DEFAULT_BOXPLOT_FACTOR;
> +		else
> +		    ylow = v[1];
>  		if (current_plot->plot_smooth == SMOOTH_ACSPLINES)
>  		    w = 1.0;	/* Unit weights */
>  		else
>  		    w = -1.0;	/* Auto-width boxes in some styles */
>  		/* Set x/y high/low to exactly [x,y] */
>  		store2d_point(current_plot, i++, v[0], v[1], 
> -						 v[0], v[0], v[1], v[1], w);
> +						 v[0], v[0], ylow, v[1], w);
>  	    }
>  	    break;
>  
> @@ -1004,7 +1007,7 @@
>  
>  		case BOXPLOT:	/* x, y, width */
>  		    store2d_point(current_plot, i++, v[0], v[1], v[0]-v[2]/2., v[0]+v[2]/2.,
> -		    		  v[1], v[1], v[2]);
> +				  DEFAULT_BOXPLOT_FACTOR, v[1], v[2]);
>  		    break;
>  
>  #ifdef EAM_OBJECTS
> @@ -1513,7 +1516,7 @@
>      /* This can happen if the user specifies a non-existent column:
>       * fall back to single-boxplot mode */
>      if (!string)
> -	return 0;
> +	return DEFAULT_BOXPLOT_FACTOR;
>  
>      /* Remove the trailing garbage, quotes etc. from the string */ 
>      trimmed_string = df_parse_string_field(string);

Bug #2
I agree there may be a bug here, but I can't reproduce exactly
what you describe.  Could you please provide a full example with
both the input and the command used to plot?

If I understand the problem case correctly, a missing column in 
the input data is a failure in its own right and the point should 
be discarded before ever reaching your new code.
The actual result seems to depend on additional factors like 
"set datafile separator". But in cases where the point is not 
discarded I don't see it incorrectly added to some other category
 - instead the plot contains an extra boxplot column with a blank
label into which the problem points are placed. 
That's arguably a correct result, although it's not what I expected.

Re: [PATCH] boxplot: distinguish prefix factors

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

On Saturday, 03 January 2015 12:32:20 PM Jouke Witteveen wrote:
> When a factor name is a prefix of another, gnuplot treats them as the same.
> Hence a datafile with
> 0	0	0	foobar
> 0	1	0	foo
> will lead to only one boxplot.
> 
> This patch fixes that issue.
> ---
> diff -Naur gnuplot-5.0.0.orig/src/plot2d.c gnuplot-5.0.0/src/plot2d.c
> --- gnuplot-5.0.0.orig/src/plot2d.c	2015-01-02 21:57:32.551558965 +0100
> +++ gnuplot-5.0.0/src/plot2d.c	2015-01-02 21:58:13.929255645 +0100
> @@ -1520,7 +1520,7 @@
>      len = strlen(trimmed_string);
>      for (label = plot->labels; label; label = label->next) {
>  	/* check if string is the same as the i-th factor */
> -	if (label->text && !strncmp(trimmed_string, label->text, len))
> +	if (label->text && !strncmp(trimmed_string, label->text, len + 1))
>  		break;
>      }

I've created a Bug tracker entry for these issues

  https://sourceforge.net/p/gnuplot/bugs/1532/

Patch 1: applied to CVS for 5.0 and 5.1

[PATCH] boxplot: revised plotting routine

[Jouke W. <j.w...@gm...>]

With a default factor identifier, the expensive filter_boxplot_factor
routine can be made obsolete. This leads to more efficient plotting of
boxplots.
---
diff -Naur gnuplot-5.0.0.orig/src/graphics.c gnuplot-5.0.0/src/graphics.c
--- gnuplot-5.0.0.orig/src/graphics.c	2014-11-22 05:12:53.000000000 +0100
+++ gnuplot-5.0.0/src/graphics.c	2015-01-03 01:24:35.787529832 +0100
@@ -107,7 +107,6 @@
 static void plot_c_bars __PROTO((struct curve_points * plot));
 static int compare_ypoints __PROTO((SORTFUNC_ARGS arg1, SORTFUNC_ARGS arg2));
 static void plot_boxplot __PROTO((struct curve_points * plot));
-static int filter_boxplot_factor __PROTO((struct curve_points *plot, int level));
 
 static void place_labels __PROTO((struct text_label * listhead, int layer, TBOOLEAN clip));
 static void place_arrows __PROTO((int layer));
@@ -2682,110 +2681,57 @@
     }
 }
 
-int
-filter_boxplot(struct curve_points *plot)
-{
-    int i;
-    int N = plot->p_count;
-
-    /* Force any undefined points to the end of the list */
-    for (i=0; i<N; i++)
-	if (plot->points[i].type == UNDEFINED)
-	    plot->points[i].y = VERYLARGE;
-
-    /* Sort the points to find median and quartiles */
-    qsort(plot->points, N, sizeof(struct coordinate), compare_ypoints);
-
-    /* Remove any undefined points */
-    while (plot->points[N-1].type == UNDEFINED)
-	N--;
-    plot->p_count = N;
-
-    return N;
-}
-
-static int
-filter_boxplot_factor(struct curve_points *plot, int level)
-{
-    int i, real_level;
-    int N = plot->p_count;
-
-    /* Do we have to show the boxplots in alphabetical order of factors? */
-    if (boxplot_opts.sort_factors && plot->boxplot_factor_order)
-	real_level = plot->boxplot_factor_order[level];
-    else
-	real_level = level;
-
-    /* If the factor doesn't match,
-     * change the point to undefined and force it to the end of the list */
-    for (i=0; i<N; i++) {
-	plot->points[i].y = plot->points[i].yhigh;
-	plot->points[i].type = INRANGE;
-	if (plot->points[i].ylow != real_level) {
-	    plot->points[i].type = UNDEFINED;
-	    plot->points[i].y = VERYLARGE;
-	    FPRINTF((stderr, "filter_boxplot_factor: rejecting point: level %d, factor %g, i %d\n", level, plot->points[i].ylow, i));
-	}
-    }
-
-    /* Sort the points to find median and quartiles */
-    qsort(plot->points, N, sizeof(struct coordinate), compare_ypoints);
-
-    /* Remove any undefined points */
-    while (plot->points[N-1].type == UNDEFINED)
-	N--;
-    plot->p_count = N;
-
-    return N;
-}
-
 static void
 plot_boxplot(struct curve_points *plot)
 {
     int N;
-    int saved_p_count;
-    struct coordinate *save_points = plot->points;
+    int remaining = plot->p_count;
+    int saved_p_count = plot->p_count;
+    struct coordinate GPHUGE *current_points = plot->points;
+    struct coordinate GPHUGE *saved_points = plot->points;
     struct coordinate candle;
+    double delta_x = 0;
     double median, quartile1, quartile3;
     double whisker_top, whisker_bot;
-    int level;
-    int levels = plot->boxplot_factors;
-    if (levels == 0)
-	levels = 1;
-    saved_p_count = plot->p_count;
-
-    for (level=0; level<levels; level++) {
-	/* Sort the points and get rid of any that are undefined */
-	/* EAM Feb 2011:  Move this to boxplot_range_fiddling()  */
-	/* N = filter_boxplot(plot);                             */
-	/* but we need filtering to make factored boxplots work:        */
-	if (levels > 1) {
-	    plot->p_count = saved_p_count;
-	    N = filter_boxplot_factor(plot, level);
-	}
-	else
-	    N = plot->p_count;
+
+    /* set N to the distance towards the first boxplot to plot */
+    N = 0;
+    if (plot->boxplot_factors > 0)
+	while (N<remaining && current_points[N].ylow < 0) N++;
+
+    do {
+	/* move to the next boxplot and count the number of its points */
+	remaining -= N;
+	if (remaining == 0)
+	    break;
+	current_points += N;
+	for (N = 0;
+	     N < remaining && current_points[N].ylow == current_points->ylow;
+	     N++);
+
+	/* Sort the points to find median and quartiles */
+	qsort(current_points, N, sizeof(struct coordinate), compare_ypoints);
 
 	/* Not enough points left to make a boxplot */
 	if (N < 4) {
-	    candle.x = plot->points->x + boxplot_opts.separation * level;
+	    candle.x = current_points->x + delta_x;
 	    candle.yhigh = -VERYLARGE;
 	    candle.ylow = VERYLARGE;
 	    goto outliers;
 	}
 
 	if ((N & 0x1) == 0)
-	    median = 0.5 * (plot->points[N/2 - 1].y + plot->points[N/2].y);
+	    median = 0.5 * (current_points[N/2 - 1].y + current_points[N/2].y);
 	else
-	    median = plot->points[(N-1)/2].y;
+	    median = current_points[(N-1)/2].y;
 	if ((N & 0x3) == 0)
-	    quartile1 = 0.5 * (plot->points[N/4 - 1].y + plot->points[N/4].y);
+	    quartile1 = 0.5 * (current_points[N/4 - 1].y + current_points[N/4].y);
 	else
-	    quartile1 = plot->points[(N+3)/4 - 1].y;
+	    quartile1 = current_points[(N+3)/4 - 1].y;
 	if ((N & 0x3) == 0)
-	    quartile3 = 0.5 * (plot->points[N - N/4].y + plot->points[N - N/4 - 1].y);
+	    quartile3 = 0.5 * (current_points[N - N/4].y + current_points[N - N/4 - 1].y);
 	else
-	    quartile3 = plot->points[N - (N+3)/4].y;
+	    quartile3 = current_points[N - (N+3)/4].y;
 
 	    FPRINTF((stderr,"Boxplot: quartile boundaries for %d points: %g %g %g\n",
 			N, quartile1, median, quartile3));
@@ -2797,14 +2743,14 @@
 	    int i;
 	    whisker_bot = quartile1 - whisker_len;
 	    for (i=0; i<N; i++)
-		if (plot->points[i].y >= whisker_bot) {
-		    whisker_bot = plot->points[i].y;
+		if (current_points[i].y >= whisker_bot) {
+		    whisker_bot = current_points[i].y;
 		    break;
 		}
 	    whisker_top = quartile3 + whisker_len;
 	    for (i=N-1; i>= 0; i--)
-		if (plot->points[i].y <= whisker_top) {
-		    whisker_top = plot->points[i].y;
+		if (current_points[i].y <= whisker_top) {
+		    whisker_top = current_points[i].y;
 		    break;
 		}
 
@@ -2815,16 +2761,16 @@
 	    int top = N-1;
 	    int bot = 0;
 	    while ((double)(top-bot+1)/(double)(N) >= boxplot_opts.limit_value) {
-		whisker_top = plot->points[top].y;
-		whisker_bot = plot->points[bot].y;
+		whisker_top = current_points[top].y;
+		whisker_bot = current_points[bot].y;
 		if (whisker_top - median >= median - whisker_bot) {
 		    top--;
-		    while ((top > 0) && (plot->points[top].y == plot->points[top-1].y))
+		    while ((top > 0) && (current_points[top].y == current_points[top-1].y))
 			top--;
 		}
 		if (whisker_top - median <= median - whisker_bot) {
 		    bot++;
-		    while ((bot < top) && (plot->points[bot].y == plot->points[bot+1].y))
+		    while ((bot < top) && (current_points[bot].y == current_points[bot+1].y))
 			bot++;
 		}
 	    }
@@ -2833,14 +2779,14 @@
 	/* Dummy up a single-point candlesticks plot using these limiting values */
 	candle.type = INRANGE;
 	if (plot->plot_type == FUNC)
-	    candle.x = (plot->points[0].x + plot->points[N-1].x) / 2.;
+	    candle.x = (current_points[0].x + current_points[N-1].x) / 2.;
 	else
-	    candle.x = plot->points->x + boxplot_opts.separation * level;
+	    candle.x = current_points->x + delta_x;
 	candle.y = quartile1;
 	candle.z = quartile3;
 	candle.ylow  = whisker_bot;
 	candle.yhigh = whisker_top;
-	candle.xlow  = plot->points->xlow + boxplot_opts.separation * level;
+	candle.xlow  = current_points->xlow + delta_x;
 	candle.xhigh = median;	/* Crazy order of candlestick parameters! */
 	plot->points = &candle;
 	plot->p_count = 1;
@@ -2850,26 +2796,23 @@
 	else
 	    plot_c_bars( plot );
 
-	plot->points = save_points;
-	plot->p_count = N;
-
 	/* Now draw individual points for the outliers */
 	outliers:
 	if (boxplot_opts.outliers) {
 	    int i,j,x,y;
 	    p_width = plot->lp_properties.p_size * term->h_tic;
 
-	    for (i = 0; i < plot->p_count; i++) {
+	    for (i = 0; i < N; i++) {
 
-		if (plot->points[i].y >= candle.ylow
-		&&  plot->points[i].y <= candle.yhigh)
+		if (current_points[i].y >= candle.ylow
+		&&  current_points[i].y <= candle.yhigh)
 		    continue;
 
-		if (plot->points[i].type != INRANGE)
+		if (current_points[i].type != INRANGE)
 		    continue;
 
 		x = map_x(candle.x);
-		y = map_y(plot->points[i].y);
+		y = map_y(current_points[i].y);
 		/* do clipping if necessary */
 		if (clip_points &&
 		    (x < plot_bounds.xleft + p_width
@@ -2880,13 +2823,16 @@
 		}
 
 		/* Separate any duplicate outliers */
-		for (j=1; (i >= j) && (plot->points[i].y == plot->points[i-j].y); j++)
+		for (j=1; (i >= j) && (current_points[i].y == current_points[i-j].y); j++)
 		    x += p_width * ((j & 1) == 0 ? -j : j);;
 
 		(term->point) (x, y, plot->lp_properties.p_type);
 	    }
 	}
-    }
+	delta_x += boxplot_opts.separation;
+    } while (current_points->ylow + 1 < plot->boxplot_factors);
+    plot->points = saved_points;
+    plot->p_count = saved_p_count;
 }
 
 
diff -Naur gnuplot-5.0.0.orig/src/graphics.h gnuplot-5.0.0/src/graphics.h
--- gnuplot-5.0.0.orig/src/graphics.h	2013-12-26 19:52:27.000000000 +0100
+++ gnuplot-5.0.0/src/graphics.h	2015-01-02 22:54:00.944166721 +0100
@@ -71,7 +71,6 @@
     enum PLOT_SMOOTH plot_smooth; /* which "smooth" method to be used? */
     double smooth_parameter;	/* e.g. optional bandwidth for smooth kdensity */
     int boxplot_factors;	/* Only used if plot_style == BOXPLOT */
-    int *boxplot_factor_order;	/* Only used if plot_style == BOXPLOT */
     int p_max;			/* how many points are allocated */
     int p_count;		/* count of points in points */
     int x_axis;			/* FIRST_X_AXIS or SECOND_X_AXIS */
@@ -112,6 +111,4 @@
 #define place_objects(listhead,layer,dimensions) /* void() */
 #endif
 
-int filter_boxplot __PROTO((struct curve_points *));
-
 #endif /* GNUPLOT_GRAPHICS_H */
diff -Naur gnuplot-5.0.0.orig/src/plot2d.c gnuplot-5.0.0/src/plot2d.c
--- gnuplot-5.0.0.orig/src/plot2d.c	2015-01-03 01:34:10.374844052 +0100
+++ gnuplot-5.0.0/src/plot2d.c	2015-01-03 02:41:33.675309714 +0100
@@ -77,6 +77,8 @@
 static void add_tics_boxplot_factors __PROTO((struct curve_points *plot));
 static void sort_boxplot_factors __PROTO((struct curve_points *plot));
 static int compare_boxplot_factors __PROTO((SORTFUNC_ARGS arg1, SORTFUNC_ARGS arg2));
+static int filter_boxplot_factor __PROTO((struct curve_points *plot, int level));
+static int compare_ylow __PROTO((SORTFUNC_ARGS arg1, SORTFUNC_ARGS arg2));
 
 /* internal and external variables */
 
@@ -187,8 +189,6 @@
 	if (cp->labels)
 	    free_labels(cp->labels);
 	cp->labels = NULL;
-	free(cp->boxplot_factor_order);
-	cp->boxplot_factor_order = NULL;
 	if (cp->z_n) {
 	    int i;
 	    for (i = 0; i < cp->n_par_axes; i++)
@@ -1587,9 +1587,7 @@
  * in the order they were found in the file, and these numbers were written into the
  * plot->points structure. To change the order in which they will be plotted, 
  * we have to sort the factor strings (which are stored in plot->labels), then 
- * fill plot->boxplot_factor_order with the order we've found. This is essentially 
- * a permutation of the sequence 0:N-1 where N is the number of levels the factor 
- * variable has (plot->boxplot_factors). */
+ * update all the factor levels in plot->points. */
 static void
 sort_boxplot_factors(struct curve_points *plot)
 {
@@ -1602,7 +1600,7 @@
     if (plot->boxplot_factors < 2 || !plot->labels || !plot->labels->next)
 	return;
     
-    temp_labels =  gp_alloc(plot->boxplot_factors * sizeof(temp_labels), "boxplot labels array");
+    temp_labels = gp_alloc(plot->boxplot_factors * sizeof(text_label *), "boxplot labels array");
     permutation = gp_alloc(plot->boxplot_factors * sizeof(int), "boxplot permutations array");
 
     /* fill pointer array by walking the linked list */
@@ -1615,23 +1613,70 @@
     }
     /* sort pointer array */
     qsort(temp_labels, plot->boxplot_factors, sizeof(text_label *), compare_boxplot_factors);
-    
-    /* read out the tags from the text_labels from the - now sorted - pointer array, 
-     * and write them into the permutation array in order */
+
+    /* update the tags from the text_labels of the - now sorted - pointer array, 
+     * and construct a translation pemutation */
     for (i=0; i<plot->boxplot_factors; i++) {
-	permutation[i] = temp_labels[i]->tag;
+	permutation[temp_labels[i]->tag] = i;
+	temp_labels[i]->tag = i;
+    }
+
+    /* update all factors */
+    /* this simplifies the plotting routine, as all boxplots end up in order */
+    for (i=0; i<plot->p_count; i++) {
+	struct coordinate *point = &plot->points[i];
+	if (point->type == UNDEFINED || point->ylow < 0 || point->ylow >= plot->boxplot_factors)
+	    continue;
+	point->ylow = permutation[(int)point->ylow];
     }
 
     /* and also re-link the list in sorted order for the tics */
     this_label = plot->labels->next = temp_labels[0];
-    for (i=0; i<plot->boxplot_factors-1; i++) {
-	this_label->next = temp_labels[i+1];
+    for (i=1; i<plot->boxplot_factors; i++) {
+	this_label->next = temp_labels[i];
 	this_label = this_label->next;
     }
     this_label->next = NULL;
     
     free(temp_labels);
-    plot->boxplot_factor_order = permutation;
+    free(permutation);
+}
+
+static int
+compare_ylow(SORTFUNC_ARGS arg1, SORTFUNC_ARGS arg2)
+{
+    struct coordinate const *p1 = arg1;
+    struct coordinate const *p2 = arg2;
+
+    if (p1->ylow > p2->ylow)
+	return (1);
+    if (p1->ylow < p2->ylow)
+	return (-1);
+    return (0);
+}
+
+static int
+filter_boxplot(struct curve_points *plot)
+{
+    int i;
+    int N = plot->p_count;
+
+    /* Force any undefined points to the end of the list */
+    for (i=0; i<N; i++)
+	if (plot->points[i].type == UNDEFINED)
+	    plot->points[i].ylow = VERYLARGE;
+
+    /* Group by the levels of the boxplot factors */
+    if (plot->boxplot_factors > 1 && boxplot_opts.sort_factors)
+	sort_boxplot_factors(plot);
+    qsort(plot->points, N, sizeof(struct coordinate), compare_ylow);
+
+    /* Remove any undefined points */
+    while (plot->points[N-1].type == UNDEFINED)
+	N--;
+    plot->p_count = N;
+
+    return N;
 }
 
 /* Autoscaling of box plots cuts off half of the box on each end. */
@@ -2821,12 +2866,10 @@
 		}
 
 		/* if needed, sort boxplot factors and assign tic labels to them */
-		if (this_plot->plot_style == BOXPLOT && this_plot->boxplot_factors > 0) {
-		     if (boxplot_opts.sort_factors)
-			sort_boxplot_factors(this_plot);
-		     if (boxplot_opts.labels != BOXPLOT_FACTOR_LABELS_OFF)
-			add_tics_boxplot_factors(this_plot);
-		}
+		if (this_plot->plot_style == BOXPLOT
+		    && this_plot->boxplot_factors > 0
+		    && boxplot_opts.labels != BOXPLOT_FACTOR_LABELS_OFF)
+		    add_tics_boxplot_factors(this_plot);
 
 		/* sort */
 		switch (this_plot->plot_smooth) {
diff -Naur gnuplot-5.0.0.orig/src/set.c gnuplot-5.0.0/src/set.c
--- gnuplot-5.0.0.orig/src/set.c	2014-11-23 19:29:17.000000000 +0100
+++ gnuplot-5.0.0/src/set.c	2015-01-02 19:42:41.906236781 +0100
@@ -1032,7 +1032,7 @@
 	    c_token++;
 	    boxplot_opts.separation = real_expression();
 	    if (boxplot_opts.separation < 0)
-		int_error(c_token-1,"separation must be > 0");
+		int_error(c_token-1,"separation must be non-negative");
 	}
 	else if (almost_equals(c_token,"lab$els")) {
 	    c_token++;

[PATCH] boxplot: fix tics placement

[Jouke W. <j.w...@gm...>]

The x-value of individual boxplots is ignored when placing tics for
multiple boxplots.

This patch fixes that issue. It requires the previous patch, which
introduces default factor identifiers. With this patch in place, there
is a case for changing the default separation value for the boxplot
style to 0.
---
diff -Naur gnuplot-5.0.0.orig/src/plot2d.c gnuplot-5.0.0/src/plot2d.c
--- gnuplot-5.0.0.orig/src/plot2d.c	2015-01-03 01:34:55.149743745 +0100
+++ gnuplot-5.0.0/src/plot2d.c	2015-01-03 01:34:10.374844052 +0100
@@ -73,7 +73,7 @@
 static void boxplot_range_fiddling __PROTO((struct curve_points *plot));
 static void histogram_range_fiddling __PROTO((struct curve_points *plot));
 static void impulse_range_fiddling __PROTO((struct curve_points *plot));
-static int check_or_add_boxplot_factor __PROTO((struct curve_points *plot, char* string, double x));
+static int check_or_add_boxplot_factor __PROTO((struct curve_points *plot, char* string, struct coordinate *cp));
 static void add_tics_boxplot_factors __PROTO((struct curve_points *plot));
 static void sort_boxplot_factors __PROTO((struct curve_points *plot));
 static int compare_boxplot_factors __PROTO((SORTFUNC_ARGS arg1, SORTFUNC_ARGS arg2));
@@ -1085,9 +1085,13 @@
 	    case BOXPLOT:	/* x, y, width, factor */
 		/* Load the coords just as we would have for 3-argument boxplot, 
 		 * index of factor in ylow , yhigh is the same as y */
-		store2d_point(current_plot, i++, v[0], v[1], v[0]-v[2]/2., v[0]+v[2]/2.,
-		    		  check_or_add_boxplot_factor(current_plot, df_tokens[3], v[0]),
-		    		  v[1], v[2]);
+		store2d_point(current_plot, i, v[0], v[1], v[0]-v[2]/2., v[0]+v[2]/2.,
+			      DEFAULT_BOXPLOT_FACTOR, v[1], v[2]);
+		if (current_plot->points[i].type != UNDEFINED)
+		    current_plot->points[i].ylow = check_or_add_boxplot_factor(
+						       current_plot, df_tokens[3],
+						       &(current_plot->points[i]));
+		i++;
 		break;
 
 
@@ -1506,7 +1510,7 @@
 
 /* Check if <string> is already among the known factors, if not, add it to the list */
 static int
-check_or_add_boxplot_factor(struct curve_points *plot, char* string, double x)
+check_or_add_boxplot_factor(struct curve_points *plot, char* string, struct coordinate *cp)
 {
     int len;
     char * trimmed_string;
@@ -1527,10 +1531,14 @@
 		break;
     }
 
-    /* not found, so we add it now */
-    if (!label)
-	label = store_label(plot->labels, &(plot->points[0]), 
-		plot->boxplot_factors++, trimmed_string, 0.0);
+    if (label) {
+	/* for consistency, we store the position corresponding to the smallest y */
+	if (cp->y < label->place.y) {
+	    label->place.x = cp->x;
+	    label->place.y = cp->y;
+	}
+    } else	/* not found, so we add it now */
+	label = store_label(plot->labels, cp, plot->boxplot_factors++, trimmed_string, 0.0);
 
     free(trimmed_string);
     return label->tag;
@@ -1556,7 +1564,7 @@
 	add_tic_user(
 	    boxplot_labels_axis,
 	    this_label->text,
-	    plot->points->x + i * boxplot_opts.separation,
+	    this_label->place.x + i * boxplot_opts.separation,
 	    -1);
 	i++;
 	this_label = this_label->next;

[PATCH] boxplot: introduce a default factor

[Jouke W. <j.w...@gm...>]

When a row in the datafile contains no factor, its y-value is stored in
place of the factor identifier, leading to ambiguities.
If the datafile contains
0	0	0	foo
0	1
The second row will be marked as part of the 'foo' boxplot.

This patch fixes that issue.
---
diff -Naur gnuplot-5.0.0.orig/src/gadgets.h gnuplot-5.0.0/src/gadgets.h
--- gnuplot-5.0.0.orig/src/gadgets.h	2015-01-02 22:06:25.488402227 +0100
+++ gnuplot-5.0.0/src/gadgets.h	2015-01-02 22:06:25.458403577 +0100
@@ -279,6 +279,8 @@
 	BOXPLOT_FACTOR_LABELS_X2
 } t_boxplot_factor_labels;
 
+#define DEFAULT_BOXPLOT_FACTOR -1
+
 typedef struct boxplot_style {
     int limit_type;	/* 0 = multiple of interquartile 1 = fraction of points */
     double limit_value;
diff -Naur gnuplot-5.0.0.orig/src/plot2d.c gnuplot-5.0.0/src/plot2d.c
--- gnuplot-5.0.0.orig/src/plot2d.c	2015-01-02 22:06:25.488402227 +0100
+++ gnuplot-5.0.0/src/plot2d.c	2015-01-02 22:08:57.411693594 +0100
@@ -910,19 +910,22 @@
 		store2d_point(current_plot, i++, v[0], v[1], v[0], v[0],
 			      v[1] - v[2], v[1] + v[2], -1.0);
 	    } else {
-		double w;
+		double ylow, w;
 		if (current_plot->plot_style == CANDLESTICKS
 		    || current_plot->plot_style == FINANCEBARS) {
 		    int_warn(storetoken, "This plot style does not work with 1 or 2 cols. Setting to points");
 		    current_plot->plot_style = POINTSTYLE;
-		}
+		} else if (current_plot->plot_style == BOXPLOT)
+		    ylow = DEFAULT_BOXPLOT_FACTOR;
+		else
+		    ylow = v[1];
 		if (current_plot->plot_smooth == SMOOTH_ACSPLINES)
 		    w = 1.0;	/* Unit weights */
 		else
 		    w = -1.0;	/* Auto-width boxes in some styles */
 		/* Set x/y high/low to exactly [x,y] */
 		store2d_point(current_plot, i++, v[0], v[1], 
-						 v[0], v[0], v[1], v[1], w);
+						 v[0], v[0], ylow, v[1], w);
 	    }
 	    break;
 
@@ -1004,7 +1007,7 @@
 
 		case BOXPLOT:	/* x, y, width */
 		    store2d_point(current_plot, i++, v[0], v[1], v[0]-v[2]/2., v[0]+v[2]/2.,
-		    		  v[1], v[1], v[2]);
+				  DEFAULT_BOXPLOT_FACTOR, v[1], v[2]);
 		    break;
 
 #ifdef EAM_OBJECTS
@@ -1513,7 +1516,7 @@
     /* This can happen if the user specifies a non-existent column:
      * fall back to single-boxplot mode */
     if (!string)
-	return 0;
+	return DEFAULT_BOXPLOT_FACTOR;
 
     /* Remove the trailing garbage, quotes etc. from the string */ 
     trimmed_string = df_parse_string_field(string);

[PATCH] boxplot: distinguish prefix factors

[Jouke W. <j.w...@gm...>]

When a factor name is a prefix of another, gnuplot treats them as the same.
Hence a datafile with
0	0	0	foobar
0	1	0	foo
will lead to only one boxplot.

This patch fixes that issue.
---
diff -Naur gnuplot-5.0.0.orig/src/plot2d.c gnuplot-5.0.0/src/plot2d.c
--- gnuplot-5.0.0.orig/src/plot2d.c	2015-01-02 21:57:32.551558965 +0100
+++ gnuplot-5.0.0/src/plot2d.c	2015-01-02 21:58:13.929255645 +0100
@@ -1520,7 +1520,7 @@
     len = strlen(trimmed_string);
     for (label = plot->labels; label; label = label->next) {
 	/* check if string is the same as the i-th factor */
-	if (label->text && !strncmp(trimmed_string, label->text, len))
+	if (label->text && !strncmp(trimmed_string, label->text, len + 1))
 		break;
     }

Re: wxT/Qt framework help book (was Fwd: Re: Last call ...)

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

On 01/02/2015 01:42 PM, Ethan A Merritt wrote:
> On Friday, 02 January, 2015 13:03:12 Daniel J Sebald wrote:
>
>>  On 01/02/2015 05:07 AM, Mojca Miklavec wrote:
>
>>
>
>>  > One tiny problem: when I ran help in wxt for the first time, the
>
>>  > dialogue window appeared. During that time the console was completely
>
>>  > unresponsive. But maybe that's the expected behaviour anyway.
>
>>  No, that's not expected. I'm wondering if there is some type of strange
>
>>  bug in the wxT terminal that manifests in different ways on different
>
>>  systems.
>
> Could it be because wxWidgets on OSX is single-threaded?

Good point.  The dialog box should be modal though...let me think about 
that one.


>>  I've noted some strange behavior (wxT terminals are always
>
>>  persistent, once in a while crashes on exit), which still exists in the
>
>>  5.1 development version.
>
> It would really help if you could capture a backtrace of such
>
> a crash.

I'll try, but it is random and the usual info seems to somewhere other 
than the terminal window.


> And what do you mean "always persistent"?
>
> Are you saying that even if you run without the persist mode
>
> the plot window still never exits?

Yes.


> Or do you just mean that the toolbar widget always defaults
>
> to "persist". If the latter, perhaps there's a corruption in
>
> ~/.gnuplot-wxt content?

Oh man, operator error!  I didn't even know such a setting existed in 
the wxt terminal.

Well, guess I'm OK with the existence of such a setting in the terminal 
window, except for the fact that there seems to be a logical conundrum 
to it with regard to a command-line persist setting.  That is, right now 
if one launches with:

gnuplot -persist

and then looks at the wxT terminal settings, the "Don't quit until all 
windows are closed (persist)" is not checked.  Shouldn't that be checked 
if "persist" actually is active?  But if that box were forced to be 
checked, it would mean that the next time gnuplot is launched wxT would 
be persistent regardless of the presence of "-persist".

Furthermore, if launching in "-persist" mode, opening the settings 
window of wxT and checking and then unchecking "Don't quit until all 
windows are closed (persist)" takes the terminal out of persist mode, 
obviating the "-persist" argument.

If the terminal is to have control of this (why it should, I'm not 
sure), then maybe there really should be a third "setting", or 
non-setting, i.e., make the checkbox non-checkable or grayed out or 
something similar.  That is, launching with "-persist" might make it so 
that the checkbox in the wxT terminal settings is gray and can't be altered.

Dan


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

-- 

Dan Sebald
email: daniel(DOT)sebald(AT)ieee(DOT)org
URL: http://www(DOT)dansebald(DOT)com

Re: wxT/Qt framework help book (was Fwd: Re: Last call ...)

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

On Friday, 02 January, 2015 13:03:12 Daniel J Sebald wrote:
> On 01/02/2015 05:07 AM, Mojca Miklavec wrote:
>  
> > One tiny problem: when I ran help in wxt for the first time, the
> > dialogue window appeared. During that time the console was completely
> > unresponsive. But maybe that's the expected behaviour anyway.
 
> No, that's not expected.  I'm wondering if there is some type of strange 
> bug in the wxT terminal that manifests in different ways on different 
> systems.  

Could it be because wxWidgets on OSX is single-threaded?

> I've noted some strange behavior (wxT terminals are always 
> persistent, once in a while crashes on exit), which still exists in the 
> 5.1 development version.

It would really help if you could capture a backtrace of such
a crash.

And what do you mean "always persistent"?
Are you saying that even if you run without the persist mode 
the plot window still never exits?
Or do you just mean that the toolbar widget always defaults
to "persist".  If the latter, perhaps there's a corruption in
~/.gnuplot-wxt content?

	Ethan