Re: Time/date autoticking --- showstopper?

[Daniel J S. <dan...@ie...>]

  Hans-Bernhard Broeker wrote:

>Gents,
>
>it seems we may have found ourselves a show-stopping bug:
>
> [ 918276 ] Irregularly spaced labels on time axis in v 3.8k.2
>
>Thanks to Chistopher Roth (cc'ed) for spotting this one.
>
>The culprit who committed the code in question is myself, but given the
>schedule of the planned release, I think we'll need all attention we can
>muster focussed on that one.  I for one won't consider the program to be
>release-worthy until we fix it.  (It's marked as release_critical for that
>reason.)
>

You didn't get much feedback on this one.  I think it is because it is 
somewhat obsure for most to follow without working with it closely.  I 
briefly looked through the code for the routines you mention and 
although I can't pinpoint things without really getting into it, maybe a 
dialogue can lead to the problem...

First, let me say that the code looks fairly well organized and logical 
so that if you find the problem, fixing for the 4.0 release wouldn't be 
shaking the tree too much.  The solution is probably just some minor 
adjustment, I would think.

>
>To easily see what the problem is, try the following script:
>
>	reset
>	set ydata time
>	set mytics
>	p [-10 : 36*60] x
>


I'm not totally sure what the problem is with this one.  Is it that 
there are only the major tics and so few of them that it is difficult to 
judge the values?  Are you saying there should be more minor tics here?

For example

    p [-10 : 36*59] x

looks pretty good, aside from the fact that the top tic annotation lies 
off the top of the X11 window.  There is a major tic spacing of 3 
minutes and minor tic spacing at every minute.

But for

    p [-10 : 36*60] x

the scale seems to jump to the hourly dynamic range, or mode, or 
whatever you want to call it.  So all of a sudden there is only one or 
possibly two major tics and no minor tics.  So that tells me the 
algorithm in quantize_time_tics() may need some adjustment.  You may 
want to stay in the minute mode just a little while longer, say twenty 
percent more.  Or it may be that you just want some minor tics in there 
to fill things out a little better.  Or, you could put major tics at 
every half hour instead of hour when in this region (i.e., just a little 
bit beyond an hours time).  Anyway, choosing the better major tic 
spacing doesn't seem like a huge issue.  (Is the "guide" parameter meant 
to be roughly the number of tics that should be?)  Perhaps you need to 
introduce a few more "ranges" inside the enumeration, e.g., 
TIMELEVEL_THIRDMINUTES, TIMELEVEL_THIRDHOURS, etc., and then add the 
appropriate cases inside the routines.

However, this example:

    p [-10 : 36*300] x

reveals a more sever problem.  Now the hourly major tics seem pretty 
good, perhaps still a bit too spaced apart.  But the minor tics aren't 
evenly spaced.  It looks as though the minor tic spacing starts out such 
that there should be 6 minor tics between major tics, but only the first 
two minor tics are displayed.  I would say this one is a bug of the typo 
kind, i.e., and "oops, didn't mean to type that" sort of thing, rather 
than a conceptual thoughto.


>Replace the numbers by whatever you like, and watch the y tics.  
>Optionally set the ytics or mytics to some explicit interval.
>
>There's a *lot* of funny things going on there.  The minitics are
>seriously ill, but the major tics aren't exactly perfect either.  The
>functions and data to inspect are all in axis.c:
>
>	t_timelevel timelevel[];
>	AXIS axis_array[];
>
>	quantize_duodecimal_tics()
>	quantize_time_tics()
>	make_auto_time_minitics()
>	time_tic_just()
>
>The main problems seem to be that interpretation of timelevel[] is
>somewhat different between quantize_time_tics() and time_tic_just().
>
>Since I invented quantize_duodecimal_tics(), timelevel[] is set by
>quantize_time_tics() to be the unit the major tic spacing it's *based* on.  
>In particular, that unit is quite often *larger* than the actual tic step,
>i.e. a tick step of 10 minutes is seen as "1/6th of an hour", so
>timelevel[] will be TIMELEVEL_HOURS.  time_tic_just() does quite a number
>of wrong things if tics are spaced as fractions of a timelevel[] unit. In
>particular it moves tics around by zeroing out fields in a time struct,
>causing them to often end up all in the same place. Christopher posted a
>patch for this, but IMHO that's not exactly correct either.
>
>Time axes are actually not all that bad, even --- the strange factor of
>twelve is tricky, but quantize_duodecimal_tics() can handle it.  The real
>bugger is with date axes.  These are (slightly, but significantly)
>irregular by definition, and that's not something the usual auto-ticking
>algorithm can do. In trying to get those right, it's very easy to break
>other aspects, and we did.
>

Well, there seems to be a large amount of code for Gnuplot implementing 
its own form of gmtime().  Yes, that is going to be involved, various 
month lengths, leap year algorithm, etc.  Too bad there isn't some way 
of translating the time values and using the existing gmtime() routine. 
 However, I don't see this as the issue for the major/minor tics.  A 
problem with this routine would only mess up the contents of the tic 
labels, e.g., wrong dates, mainly.

Are we on the same wavelength here?

Dan

-- 

Dan Sebald
email: daniel DOT sebald AT ieee DOT org
URL: http://acer-access DOT com/~dsebald AT acer-access DOT com/