#1864 boxxyerrorbar style doesn't allow pointtype when it should

[Dan Sebald]

This is for development version.

boxxyerrorbars does not allow a pointtype when it should be no different than other error bar styles. In fact, the boxxyerrorbars documentation says that a 6-field data entry is allowed which would make no sense without that point symbol in the middle of the box somewhere to show that the box is not symmetric about the central reference point.

Make the following change to the mgr.dem file:

Index: demo/mgr.dem
===================================================================
RCS file: /cvsroot/gnuplot/gnuplot/demo/mgr.dem,v
retrieving revision 1.10
diff -u -r1.10 mgr.dem
--- demo/mgr.dem    9 Apr 2011 23:50:05 -0000   1.10
+++ demo/mgr.dem    5 Oct 2016 15:42:02 -0000
@@ -53,9 +53,9 @@
 set ylabel "Power [W]"
 set title "UM1-Cell Power"
 n(x)=1.53**2*x/(5.67+x)**2
-plot [0:50] "battery.dat" t "Power" with xyerrorbars, n(x) t "Theory" w lines
+plot [0:50] "battery.dat" t "Power" with xyerrorbars pointtype 2, n(x) t "Theory" w lines
 pause -1 "Would you like boxes? (-> return)"
-plot [0:50] "battery.dat" t "Power" with boxxy, n(x) t "Theory" w lines
+plot [0:50] "battery.dat" t "Power" with boxxy pointtype 2, n(x) t "Theory" w lines
 pause -1 "Only X-Bars? (-> return)"
 plot [0:50] "battery.dat" u 1:2:3 t "Power" w xerr, n(x) t "Theory" w lines
 pause -1 "Only Y-Bars? (-> return)"

and the following error appears:

gnuplot> plot [0:50] "battery.dat" t "Power" with boxxy pointtype 2, n(x) t "Theory" w lines
                                                        ^
         "mgr.dem", line 58: warning: No pointtype specifier allowed, here

The attached diff file adds the pointtype for boxxyerrorbar. I couldn't think of any other styles that apply (BOXES maybe?).

If this change moves into the source, please let me know the version so I can make a note of the change.

[Dan Sebald]

Actually, in this change:

-    BOXXYERROR   =  8*PLOT_STYLE_BITS + (PLOT_STYLE_HAS_LINE | PLOT_STYLE_HAS_FILL),
+    BOXXYERROR   =  8*PLOT_STYLE_BITS + (PLOT_STYLE_HAS_LINE | PLOT_STYLE_HAS_POINT | PLOT_STYLE_HAS_FILL),

I probably should have removed the PLOT_STYLE_HAS_FILL flag. It doesn't make sense for an error bar to have a fill, does it?

[Ethan Merritt]

I don't get it. No points are drawn in the boxxyerror style, so how is a pointtype relevant?

[Dan Sebald]

The attached patch adds the point that is drawn. Here's the documentation for boxxyerrorbars:

 The `boxxyerrorbars` style is only relevant to 2D data plotting.  It is similar
 to the `xyerrorbars` style except that it draws rectangular areas rather than
 simple crosses.  It uses either 4 or 6 basic columns of input data.
 Additional input columns may be used to provide information such as
 variable line or fill color (see `rgbcolor variable`).

      4 columns:  x  y  xdelta  ydelta
      6 columns:  x  y  xlow  xhigh  ylow  yhigh

It's the same as xyerrorbars, except it draws boxes not crosses.

Imagine drawing error boxes with xlow,xhigh and ylow,yhigh. If there is no central point, how can the viewer know what xlow,xhigh are relative to one another?

The part I question in the documentation is "or fill color (see rgbcolor variable)". I don't see why an error box should have a fill--the fill would obscure any central point that I mentioned. If the user wants filled boxes, s/he should probably just use "boxes" style.

[Ethan Merritt]

The style draws a rectangle. It is pretty much the only way to make a plot with rectangles. If you want points also, add a second plot "with points".

Anyhow, as a practical matter gnuplot's plot command doesn't support enough input columns to describe a full set of box properties and a full set of point properties. So you need two separate plot commands to describe boxes and points. "with linespoints" already hits the same problem - if you want fully general line and point properties you need to split it into two plot components. The errorbar styles are just that moreso!

[Dan Sebald]

Oh, I'm not thinking of more inputs for data. Is that some additional ramification to the PLOT_STYLE_HAS_POINT? All I'm looking for is the cability to allow the style option of the error box just as what is currently allowed for error bars. It seems to work just right with the small attached patch. Please apply the patch and give the 'mgr.dem' example a try.

[Dan Sebald]

"It is pretty much the only way to make a plot with rectangles."

There is "boxes" style as well.

[Dan Sebald]

Well, maybe error boxes could have fill. If it were done as a solid, alpha blended fill it might not obscure the interior so much.

[Dan Sebald]

There is one that I missed, a "boxerrorbars", which is evident just looking at this diff hunk:

     XERRORBARS   =  5*PLOT_STYLE_BITS + (PLOT_STYLE_HAS_POINT | PLOT_STYLE_HAS_ERRORBAR),
     YERRORBARS   =  6*PLOT_STYLE_BITS + (PLOT_STYLE_HAS_POINT | PLOT_STYLE_HAS_ERRORBAR),
     XYERRORBARS  =  7*PLOT_STYLE_BITS + (PLOT_STYLE_HAS_POINT | PLOT_STYLE_HAS_ERRORBAR),
-    BOXXYERROR   =  8*PLOT_STYLE_BITS + (PLOT_STYLE_HAS_LINE | PLOT_STYLE_HAS_FILL),
+    BOXXYERROR   =  8*PLOT_STYLE_BITS + (PLOT_STYLE_HAS_LINE | PLOT_STYLE_HAS_POINT | PLOT_STYLE_HAS_FILL),
     BOXES        =  9*PLOT_STYLE_BITS + (PLOT_STYLE_HAS_LINE | PLOT_STYLE_HAS_FILL),
     BOXERROR     = 10*PLOT_STYLE_BITS + (PLOT_STYLE_HAS_LINE | PLOT_STYLE_HAS_FILL),

boxerrorbars is conceptually the same as boxxyerrorbars, except one dimension is restricted width. So, it too should have a point. And then there is another question of consistency. Why shouldn't the X/Y/XYERRORBARS have the PLOT_STYLE_HAS_LINE as does (did) the BOXXYERROR? The only difference between those two is that one draws a cross, the other a box.

[Ethan Merritt]

I am strictly opposed to changing existing plot styles to add a point where there has not been one. (1) It is unnecessary. (2) It breaks all previous scripts using that plot style.

"boxxy" draws boxes. No point, no errorbars. Just boxes with arbitrary x/y placement.
It was probably a mistake to include the substring "error" in the full name of the plot style.

"boxerrorbars" does something quite different. It draws boxes from 0 to y with errorbars on y. Again no point.

Neither of these styles can substitute for the other.

[Dan Sebald]

"boxxy" stands for "boxxyerrorbars", not "boxxy with an x and a y dimension". Type "help boxxy" at the gnuplot command line and "boxxyerrorbars" appears. It is, in fact, an error bar. As such, the data for the central point is already present. The central point is an inherent property of error bar. Say this is an error bar

[---------------------------------]

for which I entered x, xlow and xhigh. Can one tell what the three values are? No. How about now:

[-----------------------------*---]

Yes, with that central point, one now knows what all three values are. That central point is a defining element of a error bar (and the point and should be restricted to the same color).

There'd be no point in having a boxxyerrorbars style if one can already do two separate plots of style boxes and points and achieve the same effect. In order to get both the box and point to appear in the same key symbol, there needs to be a boxxyerrorbars that behaves just the same as xyerrorbars.

My guess is that there was an oversight when someone programmed this. Why shouldn't xyerrorbars and boxxyerrorbars behave the same behavior? Neither does the documentation for xyerrorbars say that a point can be specified, but it already can.

[Ethan Merritt]

You [and the documentation] are confused.
"with boxxy" allows you to place arbitrary rectangles anywhere on the plot.
All of the other "with box" styles are limited to drawing boxes anchored at y=0.

The fact that you can use the style to represent an error range is nice, but not really an essential attribute of the style. This is unlike the errorbars y+/-delta in a plot where the boxes extend from 0 to y.

I have modified the documentation to refer to this style as "boxxyerror" rather than "boxxyerrorbars". Perhaps I should futher modify to refer simply to "boxxy"?

[Dan Sebald]

Well, I'm confused because the documentation is pretty suggestive that this is an error bar. "It is similar to the xyerrorbars style except that it draws rectangular areas rather than simple crosses." doesn't leave much room for interpretation. All of the examples with mgr.dem are using error bars. So why wouldn't this be in the class of errorbars? The name selection "box" + "xyerrorbars" suggests someone was thinking error bars at the time.

I'd say if this style isn't intended as an error bar class, then there should be no "error" within the style name. But "boxxy" lacks consistency with other concatentated names. If there is a "boxes", shouldn't the extension be called "xyboxes", just as "xyerrorbars" is a generalization of "errorbars"?

It does seem like there should be an error box of some sort, though. There is this option:

set errorbars {small | large | fullwidth | <size>}

where "small | large" control the appearance of the error bar. (fullwidth applies only to boxplots and histograms with errorbars.) Maybe small | large | box is a possibility as those are all mutually exclusive. The problem with the "set errorbars" approach is that it doesn't allow individual control. It's fine for default settings. Maybe there should be an "errorbar type" just as there are point types and line types. Don't know.

[Ethan Merritt]

I agree that it might better be called "boxxy" going forward. That is 100% compatible with old scripts. Maybe it could have been called "xyboxes" originally, but it wasn't, and changing it now would break things.

And if people want to use it as an error box, that's completely OK. But it's still a box, not a point+bars.

Maybe there should be an "errorbar type" just as there are point types and line types. Don't know.
There is :-)
You quote the documentation for 4.6 or 5.0 but in the development version it is

Syntax:
set errorbars {small | large | fullwidth | <size>} {front | back}
{line-properties}

[Dan Sebald]

boxxyerrorbars with default pointtype -1 would remain consistent. Then create an 'xyboxes' as well with no point. Another direction is "errorpoints", just like there is an 'errorlines'. In hindsight, a syntax like

plot [0:50] "battery.dat" t "Power" lines linestyle 3 and points pointype 2
plot [0:50] "battery.dat" t "Power" points pointstyle 2 and errorbars barstyle box and lines dashtype "--"

would have been most flexible. What it boils down to is constructing that key symbol to be more complex than just a line, a point, etc.

[Ethan Merritt]

Heh. Now you are completely changing the point of discussion to constructing a key entry rather than available plot styles. I have much more sympathy with the new topic.

I'd like to see new ideas for introducing a completely flexible method for constructing a custom plot legend. Probably best to conduct this discussion on the mailing list.

The development version is not so bad for this, however. Here is an example siimlar to your case above that mixes 3 different styles of plotting and uses the "title at <x,y>" option to create the key entry:

set errorbars lt black linewidth 1.300 dashtype ".."
set key samplen 6
set border back
set style textbox opaque
set title "UM1-Cell Power" 
set xlabel "Resistance [Ohm]" 
set xrange [ 0.00 : 25.0 ]
set ylabel "Power [W]" 
n(x)=1.53**2*x/(5.67+x)**2
set lt 1 lw 1.5
set lt 2 lc "grey25" lw 2
#
plot n(x) title "model" at .8,.83, \
    'battery.dat' with boxxy title at .8,.8, \
    '' with xyerrorbars pt -1 title at .8,.8, \
    '' using 1:2:(strcol(0)) with labels boxed title "#" at .86,.8

[Dan Sebald]

The key symbol was always the intention. It's just that making boxxyerror the same as xyerror seems the simplest, most consistent approach.

Manual control of keys is welcome, but I wouldn't say overlaying key symbols the most convenient way of achieving a complex symbol. I'm sort of preferential to multiple uses of the same data set, i.e.,

plot 'my.dat' using 1:2:3 lines and errorbars and points

to construct a complex key symbol. It's the same idea as 'linespoints', but extending to 'pointsboxes' is too many combinations. The X and Y and Z approach allows the user to switch the order without consequences, whereas linespoints, pointsboxes, etc. requires memory of the additional keywords.

As for the "title at <pos>", I would say that the position should not be relative to the graph or screen. Rather the <pos> should be relative to a key box. That is, the key box becomes a plot, its own object of sorts. The benefit is that changing the position of the key is just one movement rather than having to move all the individual key entries. And why not allow an index beyond the x,y position? E.g.,

plot 'battery.dat' with points title "model" at 1, \
    'battery.dat' with boxxy title "" at 1

would create the error bars with point symbol. But what about multiple keys? How is that to be handled?