Re: Time/date autoticking --- showstopper?

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

Christopher Roth wrote:

>Dan/Hans :
>
>  
>
>>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.
>>    
>>
>
>This first example is looks ok.
>

Well, actually after your discussion and examples, I think what you have 
done is better than what is shown.  It seems what you have done is made 
things so that the major ticks always lie along the bottom and top 
borders.  (Is that correct?)  What I don't like about "test1.ps" is that 
the middle/top major tic is about two thirds the way up the left border 
instead of halfway up the left border.  With that setup it is difficult 
to get a precise guesstimate of values in between the tics.  It's as 
though your eyes can't get a handle on just exactly what the proportions 
are there.

So the more major tics in test1_fixed.ps are helpful and also the tics 
starting and stopping on borders is helpful.  It is certainly nicer and 
what you have is close if not correct.  However, could there be a minor 
tic in "test1_fixed.ps"?  Or are minor tics at fractional units not 
allowed (e.g., 2.5 minutes)?  I think you are saying they are not 
allowed, right?

>>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.
>>    
>>
>
>I have to say that Hans has great work in quantize_time_ticks(), and it
>does NOT need any adjustment.  The results from this are just fine - 
>it's just that the results are being OVERRIDDEN by this unneccesary
>'zero reset' in the time_tic_just() routine.  My proposed fix averts
>this reset until it is really needed.
>
>Take a look at the both the plot produced and contents of the 'test1.ps'
>and 'test1_fixed.ps' files in the attached tar file.  The important 
>thing to note is the number of time each of the unique time labels are 
>being drawn - the 'test1.ps' shows the '31/12/1999 23:00' label being
>drawn *12* times, and all at the _same_ place, making it look like only
>one label.  Had the minutes not been forced to 0 in the time_tic_just()
>routine, there would have been a nice set of 5-minute interval major 
>time ticks.  The '01/01/2000 00:00' label is drawn *9* times, which
>continues the 5-minute intervals, making the intended top label being 
>'00:40', which exactly correlates with the length of the axis.
>The 'test1_fixed.ps' file shows the same plot, but generated using my
>proposed fix of adding the three pairs of braces in time_tic_just().
>Since the minutes are not being forced to zero, the starting time is 
>at 23:55, rather than 23:00.  The same intended 5-minute interval is
>present, and each time label is drawn only once.
>

test2_fixed.ps looks correct to me.

>>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.
>>
>>    
>>
>
>This is the error that drove me to track this bug down.  From looking at
>the 'test2.ps' plot, it appears that every other major tic, and its
>associated minor tics are missing.  Again, the postscript file reveals
>that these labels are not lost, but are drawn on top of the previous
>one.  The first label, '23:00' is drawn twice - first for 23:00, then 
>for 23:30, except that the minutes are being forced to zero -> so it 
>goes to 23:00.  The same thing happens to all other major ticks at 
>'**:30' - they are forced to be '**:00'.
>The plot in 'test2_fixed.ps' shows the way it was intended by the 
>quantize_time_ticks() routine.  Because the minutes are not being forced
>to zero, the starting time is allowed to be at 23:30, and all the other
>major ticks at **:30 now show up where they should.
>

Well, certainly Hans wouldn't have intended to have zero spacing tics...

Anyway, it looks like the bug is near fixed, if not fixed.  Nice work.

Dan