Re: strange auto tic behavior in 3.8j with timeseries data

[Hans-Bernhard B. <br...@ph...>]

On Mon, 1 Dec 2003, Kelley, Scott wrote:

> In order to using scalable png's, 

What's a "scalable png"?  PNG is just as scalable or not as any other
pixel-based file format.  Which means: hardly at all.

> I just installed gnuplot 3.8j onto a Redhat7.2 box.  I'm trying to plot
> timeseries data. The autofreq's xtics are not behaving right (i.e. like
> they did under gnuplot 3.7).

I'm afraid "like 3.7 did" is not a particularly precise description of
"behaving right".  To put it mildly.  Timeseries autoticking in 3.7 worked
more by lucky happenstance than by design.  In particular, it quite
reliably broke on Intel FPUs because of rounding problems, as soon as any
compiler optimization was allowed, because it tried to apply *decimal*
based auto-ticking to time data, which don't adhere to decimal system in
any way.

This area has been rewritten almost completely since 3.7.  Responsibility
for it is mine, so I'll try to see how this can be fixed.

> They go to hour intervals well before they should.  And (even worse) the
> x axis gets stretched to be an hour, even if the data only covers part
> of the hour.  35 minutes seems to be about the point the problem
> manifests.

36 minutes, actually ;-)  That's 12 times 3 minutes, and that's the actual
threshold the observed behaviour relies on.  An easier way to reproduce
the problem is:

	set ydata time
	set format y '%H:%M:%S'
	p [1e4 : 1e4 + 36*60 -1] x

As given, you get 3-minute major tic intervals.  Remove the "-1", and you
get 1 hour.  I'm not entirely sure why it behaves this way --- the key
function in charge of this, quantize_time_tics() returns a quite
reasonable 5 minutes as the tic interval for an axis 36 minutes long.
The bug seems to happen in the communication between it and 
'time_tic_just' which decides on axis endpoints for the plot.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.