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

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

Major and minor ticks artifact

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

Contents

  Major and minor ticks artifact Janis Papanagnou <janis_papanagnou@hotmail.com> - 2014-03-02 18:19 +0100
    Re: Major and minor ticks artifact Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2014-03-02 20:10 +0100
      Re: Major and minor ticks artifact Janis Papanagnou <janis_papanagnou@hotmail.com> - 2014-03-14 23:54 +0100
        Re: Major and minor ticks artifact sfeam <sfeam@users.sourceforge.net> - 2014-03-14 22:17 -0700
          Re: Major and minor ticks artifact Janis Papanagnou <janis_papanagnou@hotmail.com> - 2014-03-15 10:54 +0100
            Re: Major and minor ticks artifact Karl <mail.kfr@gmx.net> - 2014-03-18 18:38 +0100
              Re: Major and minor ticks artifact Hermann Peifer <peifer@gmx.eu> - 2014-03-20 07:10 +0100
        Re: Major and minor ticks artifact Hermann Peifer <peifer@gmx.eu> - 2014-03-15 13:27 +0100
          Re: Major and minor ticks artifact Janis Papanagnou <janis_papanagnou@hotmail.com> - 2014-03-15 23:02 +0100
            Re: Major and minor ticks artifact Hermann Peifer <peifer@gmx.eu> - 2014-03-16 01:54 +0100
              Re: Major and minor ticks artifact Janis Papanagnou <janis_papanagnou@hotmail.com> - 2014-03-21 05:52 +0100
            Re: Major and minor ticks artifact Dan Luecking <LookInSig@uark.edu> - 2014-03-20 12:24 -0500
              Re: Major and minor ticks artifact Janis Papanagnou <janis_papanagnou@hotmail.com> - 2014-03-21 05:54 +0100

#2329 — Major and minor ticks artifact

I noticed an ugly artifact that at on place a minor tic is unnecessarily
displayed, and even straight *besides* the major tic. This was with a png
term definition  set term png size 800,600 . If I change that definition
to  set term png size 800,599  the artifact disappears. It's, yet again,
a work-around.

Is that how gnuplot works and how experienced people "solve" such issues,
or is there any better approach?

[toc] | [next] | [standalone]

#2331

On 02.03.2014 18:19, Janis Papanagnou wrote:
> I noticed an ugly artifact that at on place a minor tic is unnecessarily
> displayed, and even straight *besides* the major tic. This was with a png
> term definition  set term png size 800,600 . If I change that definition
> to  set term png size 800,599  the artifact disappears. It's, yet again,
> a work-around.
>
> Is that how gnuplot works and how experienced people "solve" such issues,
> or is there any better approach?

How is anyone supposed to be able to answer that if you didn't even 
start to describe what you actually did in gnuplot to get this effect?

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

#2345

On 02.03.2014 20:10, Hans-Bernhard Bröker wrote:
> On 02.03.2014 18:19, Janis Papanagnou wrote:
>> I noticed an ugly artifact that at on place a minor tic is unnecessarily
>> displayed, and even straight *besides* the major tic. This was with a png
>> term definition  set term png size 800,600 . If I change that definition
>> to  set term png size 800,599  the artifact disappears. It's, yet again,
>> a work-around.
>>
>> Is that how gnuplot works and how experienced people "solve" such issues,
>> or is there any better approach?
> 
> How is anyone supposed to be able to answer that if you didn't even start
> to describe what you actually did in gnuplot to get this effect?

I am sorry that I didn't expand on details of the code. I was hoping that
such an observation - meanwhile I'd just call it a bug[*] - is well known,
so that there's already some standard hint to that. (Has that really never
been observed before? Hard to believe, but anyway.)

What I did was defining a y-axis range with major tics=1 and minor tics=0.1
resolution, or, if you prefer actual code...

  set ytics 10
  set mytics 2
  set y2tics 1
  set my2tics 10

The range of the y2 axis (where I observed the artifact) was defined as

  set y2r [0:6]

As said, I used a workaround to adjust the png size so that the rounding
issues - as far as I suspect - eliminate each other. (Still can't believe,
though, that this is how such elementary problems are to be countered with
gnuplot.)

Thanks.

Janis

[*] I have a quite good idea how this type of bug is reflected in gnuplot
(or other application's) implementations.[**] (You can probably find it in
"What Every Computer Scientist Should Know About Floating-Point Arithmetic".)
What I'm wondering about, though, is that such an effect is observable in
such a long time existing tool.

[**] Use the following code for various values (besides 0.1, e.g. 0.2, 0.25,
0.5, 0.05) and observe the final values

   i=0.0 ; while (i<1.0) i += 0.1 ; print i

many tools will not print 1.0 for an increment of 0.1, but, as expected,
will print 1.0 for all the other values that I suggested above. There are
of course various possibilities to avoid such FP problems if incrementing
FP numbers in loops would not be done as primitive as depicted.

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

#2346

Janis Papanagnou wrote:

> On 02.03.2014 20:10, Hans-Bernhard Bröker wrote:
>> On 02.03.2014 18:19, Janis Papanagnou wrote:
>>> I noticed an ugly artifact that at on place a minor tic is
>>> unnecessarily displayed, and even straight *besides* the major tic.
>>> This was with a png
>>> term definition  set term png size 800,600 . If I change that
>>> definition
>>> to  set term png size 800,599  the artifact disappears. It's, yet
>>> again, a work-around.
>>>
>>> Is that how gnuplot works and how experienced people "solve" such
>>> issues, or is there any better approach?
>> 
>> How is anyone supposed to be able to answer that if you didn't even
>> start to describe what you actually did in gnuplot to get this
>> effect?
> 
> I am sorry that I didn't expand on details of the code. I was hoping
> that such an observation - meanwhile I'd just call it a bug[*] - is
> well known, so that there's already some standard hint to that. (Has
> that really never been observed before? Hard to believe, but anyway.)
> 
> What I did was defining a y-axis range with major tics=1 and minor
> tics=0.1 resolution, or, if you prefer actual code...
> 
>   set ytics 10
>   set mytics 2
>   set y2tics 1
>   set my2tics 10
> 
> The range of the y2 axis (where I observed the artifact) was defined
> as
> 
>   set y2r [0:6]

I am going to guess that you have misinterpreted what you are seeing in
the plot.   It is not an extra tic on any single axis.  Instead the
problem is that you are plotting two set of tics on each axis 
and since the end-points of the two axes do not match up,
neither do the tics.   

The crucial thing missing from the commands you show above is the "nomirror"
attribute.  Without it the y tics are drawn on both the right and left sides,
the y2 tics are also drawn on both the right and left sides, and
hilarity results when ymin != y2man  or ymax != y2max or both.

Note that unless you do somethine to tie them together, the y and y2
axes are scaled independently.

	Ethan






> 
> As said, I used a workaround to adjust the png size so that the
> rounding issues - as far as I suspect - eliminate each other. (Still
> can't believe, though, that this is how such elementary problems are
> to be countered with gnuplot.)
> 
> Thanks.
> 
> Janis
> 
> [*] I have a quite good idea how this type of bug is reflected in
> [gnuplot
> (or other application's) implementations.[**] (You can probably find
> it in "What Every Computer Scientist Should Know About Floating-Point
> Arithmetic".) What I'm wondering about, though, is that such an effect
> is observable in such a long time existing tool.
> 
> [**] Use the following code for various values (besides 0.1, e.g. 0.2,
> [0.25,
> 0.5, 0.05) and observe the final values
> 
>    i=0.0 ; while (i<1.0) i += 0.1 ; print i
> 
> many tools will not print 1.0 for an increment of 0.1, but, as
> expected, will print 1.0 for all the other values that I suggested
> above. There are of course various possibilities to avoid such FP
> problems if incrementing FP numbers in loops would not be done as
> primitive as depicted.

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

#2347

On 15.03.2014 06:17, sfeam wrote:
> Janis Papanagnou wrote:
> 
>> On 02.03.2014 20:10, Hans-Bernhard Bröker wrote:
>>> On 02.03.2014 18:19, Janis Papanagnou wrote:
>>>> I noticed an ugly artifact that at on place a minor tic is
>>>> unnecessarily displayed, and even straight *besides* the major tic.
>>>> This was with a png
>>>> term definition  set term png size 800,600 . If I change that
>>>> definition
>>>> to  set term png size 800,599  the artifact disappears. It's, yet
>>>> again, a work-around.
>>>>
>>>> Is that how gnuplot works and how experienced people "solve" such
>>>> issues, or is there any better approach?
>>>
>>> How is anyone supposed to be able to answer that if you didn't even
>>> start to describe what you actually did in gnuplot to get this
>>> effect?
>>
>> I am sorry that I didn't expand on details of the code. I was hoping
>> that such an observation - meanwhile I'd just call it a bug[*] - is
>> well known, so that there's already some standard hint to that. (Has
>> that really never been observed before? Hard to believe, but anyway.)
>>
>> What I did was defining a y-axis range with major tics=1 and minor
>> tics=0.1 resolution, or, if you prefer actual code...
>>
>>   set ytics 10
>>   set mytics 2
>>   set y2tics 1
>>   set my2tics 10
>>
>> The range of the y2 axis (where I observed the artifact) was defined
>> as
>>
>>   set y2r [0:6]
> 
> I am going to guess that you have misinterpreted what you are seeing in
> the plot.   It is not an extra tic on any single axis.  Instead the
> problem is that you are plotting two set of tics on each axis 
> and since the end-points of the two axes do not match up,
> neither do the tics.   
> 
> The crucial thing missing from the commands you show above is the "nomirror"
> attribute.  Without it the y tics are drawn on both the right and left sides,
> the y2 tics are also drawn on both the right and left sides, and
> hilarity results when ymin != y2man  or ymax != y2max or both.
> 
> Note that unless you do somethine to tie them together, the y and y2
> axes are scaled independently.

I have to apologize again! I really should have posted the whole gnuplot
program to not mislead the readers here. Actually I *have* the command

  set ytics nomirror

in my code! That is a sufficient command IIUC? But, in addition, the two
y-axis tics also always correlate; the ranges are choosen so that the y2
axis' tics are always a superset of the y axis. The y-range is of size 60
with major tics every 10 steps and minor tics every 5 units, defined as

  set ytics 10
  set mytics 2

So, IIUC, I have implemented _two separate means_ to not make happen what
you assumed.

You can inspect the outcome at

  http://volatile.gridbug.de/ytics599.png   ## looks ok
  http://volatile.gridbug.de/ytics600.png   ## y2 artifact at y-value 1

and find the gnuplot definitions of the test program (for ok case "599")
here

  http://volatile.gridbug.de/ytics

Thanks.

Janis

> 
> 	Ethan
> 

[...]

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

#2351

Am 15.03.2014 10:54, schrieb Janis Papanagnou:

>   set ytics nomirror
> 

> 
> and find the gnuplot definitions of the test program (for ok case "599")
> here
> 
>   http://volatile.gridbug.de/ytics
> 

I stripped down your example to only reproduce the problem:

======
set term png size 800,600
set title "wrong mtic position"
set xlabel "X"

set yr [0:6]
set mytics 10

set output "ymtics.png"
plot 0
set output
=========

Really looks like a bug resulting from accumulating rounding errors.
You should file it on

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

  K

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

#2358

On 2014-03-18 18:38, Karl wrote:
>
> Really looks like a bug resulting from accumulating rounding errors.
> You should file it on
>

One could file (ahem) many bugs related to the FP magic in axis.c, and 
the repeated use of floor() and ceil() functions and other stuff that 
eventually still can't avoid ... rounding errors. The cure is to work 
with integers, as Janis explained in a later mail.

Hermann

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

#2348

On 2014-03-14 23:54, Janis Papanagnou wrote:
>
> As said, I used a workaround to adjust the png size so that the rounding
> issues - as far as I suspect - eliminate each other. (Still can't believe,
> though, that this is how such elementary problems are to be countered with
> gnuplot.)
>

I just looked into the source code of axis.c [1], I never did that 
before. As an outspoken non-programmer, I looked more into the comments 
than into the actual code. I hope that I was looking into the right 
piece of code in the first place.

Anyway, a programmer with initials "HBB" (no idea who this could be) 
seems to be well aware of FP issues, s/he uses floor() and ceil() to 
correct potential issues, but eventually states: "getting desperate...", 
etc. All these comments are 12 years old, as it looks like.

So there seems to be no real cure for the issue. IIRC, I occasionally 
defined a png size of something like 600,800.1 or some such to make 
similar issues go away. This is not very elegant and it basically means 
that I was "chasing the devil with the help of Beelzebub", as we say in 
German. But there seems to be little else that one can do.

Hermann

[1] 
http://gnuplot.cvs.sourceforge.net/viewvc/gnuplot/gnuplot/src/axis.c?revision=1.130&view=markup

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

#2349

On 15.03.2014 13:27, Hermann Peifer wrote:
> On 2014-03-14 23:54, Janis Papanagnou wrote:
>>
>> As said, I used a workaround to adjust the png size so that the rounding
>> issues - as far as I suspect - eliminate each other. (Still can't believe,
>> though, that this is how such elementary problems are to be countered with
>> gnuplot.)
>>
> 
> I just looked into the source code of axis.c [1], I never did that before. As
> an outspoken non-programmer, I looked more into the comments than into the
> actual code. I hope that I was looking into the right piece of code in the
> first place.

Thanks for the link; I (briefly) looked into the code.

> 
> Anyway, a programmer with initials "HBB" (no idea who this could be) seems to
> be well aware of FP issues, s/he uses floor() and ceil() to correct potential
> issues, but eventually states: "getting desperate...",

Not surprising; just using rounding functions does not necessarily solve the
inherent problem - that is; *if* it is the problem I suspected.

> etc. All these comments are 12 years old, as it looks like.
> 
> So there seems to be no real cure for the issue.

I have a different opinion here. First, looking at the variable names,[*] the
code seems to use tic *increments*, which would actually lead to the problem
that I illustrated with my while-loop code upthread. There are IMO various
ways how to avoid the problem; the key is to not build the tics incrementally
but absolutely. You would better iterate over an _integer_ range, the number
of tics[**] - this is also the value that you already have available, BTW -,
and multiply for every tic the counted integer number with the FP increment.
To illustrate in a fragment of pseudo-code

    ## example range [ 0.0 .. 1.0 ], with inc=0.1
    ntics = int((1.0 - 0.0)/inc)  ## actually not necessary to calculate,
                                  ## 'ntics' is what is defined in gnuplot
    for (z=0; z<=ntics; z++)      ## integer valued/incremented loop, not FP
        x = z*inc                 ## absolute calculation

    if (x != 1) print "bad"
    else        print "good"

This way you don't propagate the binary representation errors of the specific
(but common!) increment "0.1".

But you can look at it also in a more fundamental way; the major tics *are*
placed at correct position, so there's no reason to not be able to place the
minor tics as well at the correct position; the value "1" *is*, by all means,
and even in a binary encoding, correctly representable. The problem, as I
suspect, is that the tics are (presumedly[***]) calculated incrementally
instead of absolutely.[****]

I created a set of plots with the y2tics parameter varied (with values 2, 4,
5, 10, 20, 25), and the artifact is only visible at t=10 (with a incr of 0.1)!

> IIRC, I occasionally defined a png size of something like 600,800.1

Oh, I didn't knew that it's possible to define [virtual] fractions of pixels.

> or some such to make similar issues go
> away. This is not very elegant and it basically means that I was "chasing the
> devil with the help of Beelzebub", as we say in German.

I agree with that.

> But there seems to be little else that one can do.

Fixing the code? ;-)

But, yes, for practical purposes using the current version I agree.

Janis

[*] I also didn't analyse the code in depth. Specifically I didn't find the
loop in the code referenced by the link.

[**] Additionally you could (but need not, if implemented correctly) iterate
over just N-1 (instead of N) values in case there are major tics defined and
the major tic values a subset of the minor tic values.

[***] Please CMIIW.

[****] Though, now that I've seen the actual code I am even less optimistic
about the adequateness of the gnuplot implementation; that all looks too
much as not having addressed the specific problem correctly with ineffective
ad hoc "fixes".

> 
> [1]
> http://gnuplot.cvs.sourceforge.net/viewvc/gnuplot/gnuplot/src/axis.c?revision=1.130&view=markup

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

#2350

On 2014-03-15 23:02, Janis Papanagnou wrote:
> You would better iterate over an _integer_ range, the number
> of tics[**] - this is also the value that you already have available, BTW -,
> and multiply for every tic the counted integer number with the FP increment.
> To illustrate in a fragment of pseudo-code
>
>      ## example range [ 0.0 .. 1.0 ], with inc=0.1

Thanks for explaining and illustrating the issue. Increments of 0.1 are 
indeed a pain. People should simply change their thinking and coding to 
inc=0.125, or apply the integer method you described.

Hermann

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

#2363

On 16.03.2014 01:54, Hermann Peifer wrote:
> On 2014-03-15 23:02, Janis Papanagnou wrote:
>> To illustrate in a fragment of pseudo-code
>>
>>      ## example range [ 0.0 .. 1.0 ], with inc=0.1
> 
> [...] Increments of 0.1 are indeed
> a pain. People should simply change their thinking and coding to inc=0.125, or
> apply the integer method you described.

The problem with using 0.125 instead of 0.1 is that the former may not be
what the end-user wants to see. After all we are looking at the visible
application domain, not at a pure internal coding domain. Any discrepancy
between those domains must be solved by the programs that implement a task.
And since it's a well-known problem where there existed long time existing
(or long forgotten?) approaches I see no obstacle that couldn't be overcome.

Janis

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

#2359

On Sat, 15 Mar 2014 23:02:34 +0100, Janis Papanagnou
<janis_papanagnou@hotmail.com> wrote:

>On 15.03.2014 13:27, Hermann Peifer wrote:
>>http://gnuplot.cvs.sourceforge.net/viewvc/gnuplot/gnuplot/src/axis.c?revision=1.130&view=markup

>Thanks for the link; I (briefly) looked into the code.

[snipped]

>
>[*] I also didn't analyse the code in depth. Specifically I didn't find the
>loop in the code referenced by the link.

I believe it is the for-loop beginning on line 1290:
  for (mplace = ministart; mplace < miniend; mplace += ministep) {
  ...
It indeed computes locations by cumulative addition. 

I once had to do a similar thing in Metafont code (not with tics, but
the principle is the same) and ultimately settled on a counted loop,
with a calculation of location at each step. It is less efficient, 
but more accurate. 


Dan
To reply by email, change LookInSig to luecking

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

#2364

On 20.03.2014 18:24, Dan Luecking wrote:
> On Sat, 15 Mar 2014 23:02:34 +0100, Janis Papanagnou
> <janis_papanagnou@hotmail.com> wrote:
>>
>> [*] I also didn't analyse the code in depth. Specifically I didn't find the
>> loop in the code referenced by the link.
> 
> I believe it is the for-loop beginning on line 1290:
>   for (mplace = ministart; mplace < miniend; mplace += ministep) {
>   ...
> It indeed computes locations by cumulative addition. 

Thanks for the code reference and for the confirmation!

> 
> I once had to do a similar thing in Metafont code (not with tics, but
> the principle is the same) and ultimately settled on a counted loop,
> with a calculation of location at each step. It is less efficient, 
> but more accurate. 

Exactly.

Janis

[toc] | [prev] | [standalone]

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

csiph-web