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


Groups > comp.graphics.apps.gnuplot > #2349

Re: Major and minor ticks artifact

From Janis Papanagnou <janis_papanagnou@hotmail.com>
Newsgroups comp.graphics.apps.gnuplot
Subject Re: Major and minor ticks artifact
Date 2014-03-15 23:02 +0100
Organization Aioe.org NNTP Server
Message-ID <lg2ill$a1i$1@speranza.aioe.org> (permalink)
References <levp7j$tvo$1@speranza.aioe.org> <bnhe21F5utsU1@mid.dfncis.de> <lg01bh$dlr$1@speranza.aioe.org> <53244732.8080404@gmx.eu>

Show all headers | View raw


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

Back to comp.graphics.apps.gnuplot | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

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

csiph-web