Menu
▾
▴
gnuplot-beta
|
From: Jouke W. <j.w...@gm...> - 2015-01-03 11:39:23
|
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;
|
|
From: Ethan A M. <sf...@us...> - 2015-01-07 01:46:16
|
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? |
|
From: Jouke W. <j.w...@gm...> - 2015-01-10 12:27:57
|
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 |
