Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.graphics.apps.gnuplot > #2349
| 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> |
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 | Next — Previous in thread | Next in thread | Find similar
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