Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.graphics.apps.gnuplot > #3043 > unrolled thread

Labelling bug with xtics offset if y2-axis is activated

Back to article view | Back to comp.graphics.apps.gnuplot

Contents

  Labelling bug with xtics offset if y2-axis is activated Janis Papanagnou <janis_papanagnou@hotmail.com> - 2015-08-17 22:14 +0200
    Re: Labelling bug with xtics offset if y2-axis is activated Karl-Friedrich Ratzsch <mail.kfr@gmx.net> - 2015-08-18 02:45 +0200
      Re: Labelling bug with xtics offset if y2-axis is activated sfeam <sfeam@users.sourceforge.net> - 2015-08-17 22:13 -0700
        Re: Labelling bug with xtics offset if y2-axis is activated Janis Papanagnou <janis_papanagnou@hotmail.com> - 2015-08-18 14:17 +0200
          Re: Labelling bug with xtics offset if y2-axis is activated Karl-Friedrich Ratzsch <mail.kfr@gmx.net> - 2015-08-18 15:22 +0200
          Re: Labelling bug with xtics offset if y2-axis is activated sfeam <sfeam@users.sourceforge.net> - 2015-08-18 21:37 -0700
      Re: Labelling bug with xtics offset if y2-axis is activated Janis Papanagnou <janis_papanagnou@hotmail.com> - 2015-08-18 14:27 +0200
        Re: Labelling bug with xtics offset if y2-axis is activated Karl-Friedrich Ratzsch <mail.kfr@gmx.net> - 2015-08-18 14:57 +0200

#3043 — Labelling bug with xtics offset if y2-axis is activated

Can someone who is running an actual gnuplot version please confirm
whether this bug (detected in release 4.4) is still present in the
current release. The wrong behaviour can be found in file out2.png
(see full link given below). - If so, I'd file a bug report...

Here is the complete testcase code:

    set term png medium
    set xdata time
    set format x "%a"
    set timefmt "%Y-%m-%d"
    set xlabel "Date"
    set ylabel "Value"
    # set y2label "Other"
    set xtics 86400
    set mxtics 8
    set ytics 10
    set mytics 2
    # set y2tics 1
    # set my2tics 10
    set xtics offset first 86400/2
    set ytics nomirror
    set term png size 800, 599
    set output "out.png"
    plot "data" using 1:3 axis x1y2 title 'One' smooth csplines lt 3, \
         "data" using 1:2           title 'Two' smooth csplines lt 1

and test data:

    2010-01-15 10 2
    2010-01-16 17 0
    2010-01-17 12 1
    2010-01-20 11 5
    2010-01-22 17 5
    2010-01-23 19 2
    2010-01-25 15 1

The result with the three y2-definitions disabled can be found here:

    http://volatile.gridbug.de/out1.png

and the result with the three y2-definitions active can be seen here:

    http://volatile.gridbug.de/out2.png

As you can see, in the second case the X-axis annotation is flawed, it
contains a spurious "Mon" tag off the drawing area.

Is that misbehaviour still the case with the current gnuplot version, so
that a bug-report shall be issued?

Janis

[toc] | [next] | [standalone]

#3044

Am 17.08.2015 um 22:14 schrieb Janis Papanagnou:

> As you can see, in the second case the X-axis annotation is flawed, it
> contains a spurious "Mon" tag off the drawing area.
> 
> Is that misbehaviour still the case with the current gnuplot version, so
> that a bug-report shall be issued?


As expected, yes. I'm not sure this qualifies as a bug, but one
could argue that a ticslabel that gets shifted outside of the axis
range should not get printed any more.

Simpler test case is this:

	set xtics 1 offset first 0.5
	set rmargin at screen 0.8
 	plot [0:10] x

(Without the second y axis + y2label, the spurious xticlabel is
outside of the canvas and thus invisible)

A very easy workaround is to limit the range of the ticslabels to be
produced

	set xtics 0,1,9 offset first 0.5

[toc] | [prev] | [next] | [standalone]

#3045

Karl-Friedrich Ratzsch wrote:

> Am 17.08.2015 um 22:14 schrieb Janis Papanagnou:
> 
>> As you can see, in the second case the X-axis annotation is flawed,
>> it contains a spurious "Mon" tag off the drawing area.
>> 
>> Is that misbehaviour still the case with the current gnuplot version,
>> so that a bug-report shall be issued?
> 
> 
> As expected, yes. I'm not sure this qualifies as a bug, but one
> could argue that a ticslabel that gets shifted outside of the axis
> range should not get printed any more.

I do not consider it a bug.
If the user has a reason to shift all the labels to the left or right,
why should the program suddenly not draw one?  If it were my plot in
that case, I'd be very annoyed if the label were suddenly not plotted
at all just because I gave an offset.


By the way.  As to why no bug report has previously been filed
for "set [xy]tics offset <xdel>", my guess is that people accomplish
essentially the same thing by changing the format instead.
E.g.
     set xtics format "   %.2g" left


	Ethan

> 
> Simpler test case is this:
> 
> set xtics 1 offset first 0.5
> set rmargin at screen 0.8
>  plot [0:10] x
> 
> (Without the second y axis + y2label, the spurious xticlabel is
> outside of the canvas and thus invisible)
> 
> A very easy workaround is to limit the range of the ticslabels to be
> produced
> 
> set xtics 0,1,9 offset first 0.5

[toc] | [prev] | [next] | [standalone]

#3046

On 18.08.2015 07:13, sfeam wrote:
> Karl-Friedrich Ratzsch wrote:
> 
>> Am 17.08.2015 um 22:14 schrieb Janis Papanagnou:
>>
>>> As you can see, in the second case the X-axis annotation is flawed,
>>> it contains a spurious "Mon" tag off the drawing area.
>>>
>>> Is that misbehaviour still the case with the current gnuplot version,
>>> so that a bug-report shall be issued?
>>
>>
>> As expected, yes. I'm not sure this qualifies as a bug, but one
>> could argue that a ticslabel that gets shifted outside of the axis
>> range should not get printed any more.

I have a strong opinion about that; and the reason you gave is exactly
what I think. (More rationales below.)

> 
> I do not consider it a bug.
> If the user has a reason to shift all the labels to the left or right,
> why should the program suddenly not draw one? 

Because there should be clipping functionality active; as other software
sensibly does in similar cases. Moreover; if you compare the two posted
cases you see that in the first output, despite the shift, the label is
*not* printed. In the first case it's outside the drawing area and not
printed and in the second case it's outside the drawing area and printed;
it should at least be handled consistently. But in both cases there are
also no data points associated; data is restricted to the drawing area.

(Mind; the label shifting in case of dates on the axis had already been
a workaround. - Is it sensible if you label, say, days at the start of
the day (instead of the mid of the day), or label years at 1st January
(instead of the mid of the year)? - This just as a note aside. - The
gnuplot concept is very primitive here; it assumes "Monday" to have to
mean "Monday, 00:00", and "2015" to mean "2015-01-01". For date ranges
labels this is usually - and if you think about it also conceptually;
compare date data points vs. date ranges - inappropriate. YMMV.)

> If it were my plot in
> that case, I'd be very annoyed if the label were suddenly not plotted
> at all just because I gave an offset.

The label should only be clipped if it's outside the drawing area; in
that case you also have no data points or curves outside the drawing
area which would make a label meaningful.

Given the "featuritis" way of gnuplot design (as some previous comment
suggested), a new feature "set really-clip-to-drawing-area" (instead
of a correcture) might be more in the spirit of gnuplot users? - No,
I'm not, or only partly serious and partly sarcastic. The serious part
is that, whatever the default behaviour (sensible or not) would be,
you would have explicit control by a boolean flag about the actual
behaviour, whether the drawing area margins are respected or not. From
a user's perspective I'd consider that at least more user friendly than
any hard coded tics solution, or any solution that's only applicable
if the data range is known in advance.

> 
> 
> By the way.  As to why no bug report has previously been filed
> for "set [xy]tics offset <xdel>", my guess is that people accomplish
> essentially the same thing by changing the format instead.
> E.g.
>      set xtics format "   %.2g" left

The hard-coded spaces look like the format would be depending on the
actual number of tics; right? But this would qualify as an unrealiable
hack, since this precondition is not fulfilled; it's depending on the
actual data set. (YMMV, of course.)

So one opinion here is "maybe it's a bug", the other one "it's no bug".

Anyway, beside getting feedback for the current version - which would
give me a reason to update the software -, one reason whyI posted was
get opinions. The other reason was the hint (elsewhere) to file bug
reports. Given that this - IMO obvious - misbehaviour is still disputed
and argued about I'll abstain from further actions.

Thanks, Karl and Ethan, for your feedback.

Janis

> [...]

[toc] | [prev] | [next] | [standalone]

#3049

Am 18.08.2015 um 14:17 schrieb Janis Papanagnou:
> On 18.08.2015 07:13, sfeam wrote:
>> Karl-Friedrich Ratzsch wrote:
>>
>>> Am 17.08.2015 um 22:14 schrieb Janis Papanagnou:
>>>
>>>> As you can see, in the second case the X-axis annotation is flawed,
>>>> it contains a spurious "Mon" tag off the drawing area.

>>> As expected, yes. I'm not sure this qualifies as a bug, but one
>>> could argue that a ticslabel that gets shifted outside of the axis
>>> range should not get printed any more.
> 
> I have a strong opinion about that; and the reason you gave is exactly
> what I think. (More rationales below.)
> 
>>
>> I do not consider it a bug.
>> If the user has a reason to shift all the labels to the left or right,
>> why should the program suddenly not draw one? 
> 
> Because there should be clipping functionality active; as other software
> sensibly does in similar cases. Moreover; if you compare the two posted
> cases you see that in the first output, despite the shift, the label is
> *not* printed. In the first case it's outside the drawing area and not
> printed and in the second case it's outside the drawing area and printed;

In the first case it is outside of the canvas, so you couldn't see
it even if it was not clipped.

Janis, this is stupid. Gnuplot cannot know what exactly the user
wants. If you shift your ticslabels, how should the software decide
when exactly one must be removed? Perhaps i only shift it by 1/10th
of the distance, because i think that looks better, and don't want
to loose the last one! It's my prerogative!

The one way to "fix" this in a sensible way is a new feature for
"set xtics", an options "inbetween" that puts the label "zero" not
on 0 but between 0 and 1.

That'd be quite useful. Go ahead an propose it on the tracker on
sf.net, if you like.

  Karl

[toc] | [prev] | [next] | [standalone]

#3050

Janis Papanagnou wrote:

> On 18.08.2015 07:13, sfeam wrote:
>> Karl-Friedrich Ratzsch wrote:
>> 
>>> Am 17.08.2015 um 22:14 schrieb Janis Papanagnou:
>>>
>>>> As you can see, in the second case the X-axis annotation is flawed,
>>>> it contains a spurious "Mon" tag off the drawing area.
>>>>
>>>> Is that misbehaviour still the case with the current gnuplot
>>>> version, so that a bug-report shall be issued?
>>>
>>>
>>> As expected, yes. I'm not sure this qualifies as a bug, but one
>>> could argue that a ticslabel that gets shifted outside of the axis
>>> range should not get printed any more.
> 
> I have a strong opinion about that; and the reason you gave is exactly
> what I think. (More rationales below.)
> 
>> 
>> I do not consider it a bug.
>> If the user has a reason to shift all the labels to the left or
>> right, why should the program suddenly not draw one?
> 
> Because there should be clipping functionality active; as other
> software sensibly does in similar cases. Moreover; if you compare the
> two posted cases you see that in the first output, despite the shift,
> the label is *not* printed. In the first case it's outside the drawing
> area and not printed and in the second case it's outside the drawing
> area and printed; it should at least be handled consistently. But in
> both cases there are also no data points associated; data is
> restricted to the drawing area.
>[snip]
> 
>> If it were my plot in
>> that case, I'd be very annoyed if the label were suddenly not plotted
>> at all just because I gave an offset.
> 
> The label should only be clipped if it's outside the drawing area; in
> that case you also have no data points or curves outside the drawing
> area which would make a label meaningful.

The rationale for clipping is this:

(1) If an element is part of the data being plotted, it is clipped to the
interior of the graph box (graph coordinate range [0:1]).
This includes labels generated by "plot $foo with labels".

(2) If an element is not part of the graph, i.e. labels generated by
"set label", it is clipped to the canvas (screen coordinate range [0:1].

Tic and axis labels are outside the graph box, and therefore fall in
category 2.   On the other hand, if you generate tic labels from the
data, as in "plot $foo using 1:2:xticlabel(3)" then they would indeed
be clipped to the plot since the data points that generate them are
clipped by (1).

	Ethan


> Given the "featuritis" way of gnuplot design (as some previous comment
> suggested), a new feature "set really-clip-to-drawing-area" (instead
> of a correcture) might be more in the spirit of gnuplot users? - No,
> I'm not, or only partly serious and partly sarcastic. The serious part
> is that, whatever the default behaviour (sensible or not) would be,
> you would have explicit control by a boolean flag about the actual
> behaviour, whether the drawing area margins are respected or not. From
> a user's perspective I'd consider that at least more user friendly
> than any hard coded tics solution, or any solution that's only
> applicable if the data range is known in advance.
> 
>> 
>> 
>> By the way.  As to why no bug report has previously been filed
>> for "set [xy]tics offset <xdel>", my guess is that people accomplish
>> essentially the same thing by changing the format instead.
>> E.g.
>>      set xtics format "   %.2g" left
> 
> The hard-coded spaces look like the format would be depending on the
> actual number of tics; right? But this would qualify as an unrealiable
> hack, since this precondition is not fulfilled; it's depending on the
> actual data set. (YMMV, of course.)
> 
> So one opinion here is "maybe it's a bug", the other one "it's no
> bug".
> 
> Anyway, beside getting feedback for the current version - which would
> give me a reason to update the software -, one reason whyI posted was
> get opinions. The other reason was the hint (elsewhere) to file bug
> reports. Given that this - IMO obvious - misbehaviour is still
> disputed and argued about I'll abstain from further actions.
> 
> Thanks, Karl and Ethan, for your feedback.
> 
> Janis
> 
>> [...]

[toc] | [prev] | [next] | [standalone]

#3047

On 18.08.2015 02:45, Karl-Friedrich Ratzsch wrote:
> Am 17.08.2015 um 22:14 schrieb Janis Papanagnou:
> 
>> As you can see, in the second case the X-axis annotation is flawed, it
>> contains a spurious "Mon" tag off the drawing area.
>>
>> Is that misbehaviour still the case with the current gnuplot version, so
>> that a bug-report shall be issued?
> 
> 
> As expected, yes. I'm not sure this qualifies as a bug, but one
> could argue that a ticslabel that gets shifted outside of the axis
> range should not get printed any more.
> 
> Simpler test case is this:
> 
> 	set xtics 1 offset first 0.5
> 	set rmargin at screen 0.8
>  	plot [0:10] x
> 
> (Without the second y axis + y2label, the spurious xticlabel is
> outside of the canvas and thus invisible)
> 
> A very easy workaround is to limit the range of the ticslabels to be
> produced
> 
> 	set xtics 0,1,9 offset first 0.5
> 

IIUC, these are hard coded ranges. Can you please explain how this "easy
workaround" will have to be defined in the general case (the case I have)
where there's varying data scales depening on the actual data? Say, where
one data set covers the range 2004-2015, another data range will cover
2009-2012.

Thanks.

Janis

[toc] | [prev] | [next] | [standalone]

#3048

Am 18.08.2015 um 14:27 schrieb Janis Papanagnou:
> On 18.08.2015 02:45, Karl-Friedrich Ratzsch wrote:
>> 	set xtics 1 offset first 0.5
>> 	set rmargin at screen 0.8
>>  	plot [0:10] x
>>
>> A very easy workaround is to limit the range of the ticslabels to be
>> produced
>>
>> 	set xtics 0,1,9 offset first 0.5
>>
> 
> IIUC, these are hard coded ranges. Can you please explain how this "easy
> workaround" will have to be defined in the general case (the case I have)
> where there's varying data scales depening on the actual data? Say, where
> one data set covers the range 2004-2015, another data range will cover
> 2009-2012.

Do a test plot (or use the "stats" command in gnuplot >4.6) to find
out your actual data range (it's in the GPVAL_ variables after each
plot) and then limit it accordingly.

Or try to get the information from somewhere else. The file name
perhaps? Or use the shell() command to extract it from your data
file with the help of grep.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.graphics.apps.gnuplot

csiph-web