Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.datemas.de!rt.uk.eu.org!aioe.org!.POSTED!not-for-mail From: Janis Papanagnou Newsgroups: comp.graphics.apps.gnuplot Subject: Re: Major and minor ticks artifact Date: Fri, 14 Mar 2014 23:54:45 +0100 Organization: Aioe.org NNTP Server Lines: 56 Message-ID: References: NNTP-Posting-Host: RYXWUwPSGYWrJViRnQ40Lw.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit 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: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.