[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
datetick tick labels [WAS: Re: Patch for datetick.m to improve ML compat
From: |
Philip Nienhuis |
Subject: |
datetick tick labels [WAS: Re: Patch for datetick.m to improve ML compatibiity] |
Date: |
Sun, 24 Jan 2010 21:38:59 +0100 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.22) Gecko/20090605 SeaMonkey/1.1.17 |
John W. Eaton wrote:
On 20-Jan-2010, Philip Nienhuis wrote:
| While Matlab's datetick.m can handle plots without any actual argument
| supplied (and then defaults to "x-axis" and an optimal tick format for
<long snip>
I checked in the following change to fix these problems:
http://hg.savannah.gnu.org/hgweb/octave/rev/c2f1cdb59821
Now datetick succeeds with no arguments, but I don't think it is
generating the correct tick labels. I'm seeing
00:00 05:00 10:00 15:00 20:00 01:00
What should the labels be when the x-axis range is [0, 1],
That seems debatable; I'm afraid that is valid for much of datetick's
output.
I don't have Matlab at hand as a guide either. Do you want octave to
completely mimic ML's datetick?
AFAIK datetick is meant for a quick provisional formatting of time axes,
including tick formats and re-scaling of axis limits and tick intervals.
IMO datetick as it stands does a fairly good job. However the scaling
logic seems too general to properly address ranges which are not
10-based, viz. minutes/hours (60 seconds/minutes), days (24 hours),
weeks (7 days) & years (12 months).
In your example, the 24 hours in [0 1] are rounded to a multiple of 5
hour tick intervals, so that's why you get 01:00 as the last tick.
. . . . . . . . . . . . . . . and what
change in datetick is needed?
A "quick and rough" solution is to simply change line 270 in the last
datetick.m version:
ticint = 5;
into:
ticint = 4;
as that happens to help "polish" quite a number of time ranges. But it
may turn out less favorable in other cases (not that I've hit them).
I did encounter quite a number of examples where ticks were repeated, e.g.
"Fri Fri Sat Sat Sat Sun"
and some even more ugly cases (e.g. [0 375]).
unique() might help there but I'm insufficiently familiar with the plot
functions & classes to solve this particular issue.
I'd suggest to leave datetick.m as it currently is after your patch,
maybe only change line 270.
If better axis scaling and ticks are needed, dateaxis.m has "form",
"keeplimits" and "keepticks" arguments, and for more demanding
situations there are other commands and routines.
My original posting was about Matlab compatibility when calling
datetick, and that has already been solved.
Philip