Path: csiph.com!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail
From: Janis Papanagnou <janis_papanagnou@hotmail.com>
Newsgroups: comp.graphics.apps.gnuplot
Subject: Re: Major and minor ticks artifact
Date: Sat, 15 Mar 2014 23:02:34 +0100
Organization: Aioe.org NNTP Server
Lines: 95
Message-ID: <lg2ill$a1i$1@speranza.aioe.org>
References: <levp7j$tvo$1@speranza.aioe.org> <bnhe21F5utsU1@mid.dfncis.de> <lg01bh$dlr$1@speranza.aioe.org> <53244732.8080404@gmx.eu>
NNTP-Posting-Host: RYXWUwPSGYWrJViRnQ40Lw.user.speranza.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130330 Thunderbird/17.0.5
X-Notice: Filtered by postfilter v. 0.8.2
Xref: csiph.com comp.graphics.apps.gnuplot: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