Thu 16 Mar 2017 04:30:33 PM UTC, comment #12:
Slowly clearing these bug reports. I pushed the change for datetick to the stable branch here (http://hg.savannah.gnu.org/hgweb/octave/rev/6cbf5c2d4d55). I made two changes: 1) I added a space between the function name and opening parenthesis which is Octave style, and 2) I added the bug number to the commit message and a description of what was done to the datetick.m file.
|
Thu 16 Mar 2017 02:30:27 PM UTC, comment #11:
Here is an example why the current version with just the fix in datenum may produce misleading plots in some cases.
The example is attached. One tick is placed at midnight, the other at noon.
(file #40016)
|
Mon 13 Mar 2017 08:46:55 AM UTC, comment #10:
@Rik: The old datetick using the new datenum will place ticks at
feb-15 00:00 for a 28 day february
feb-15 12:00 for a 29 day leap february
xxx-16 00:00 for a 30 day month
xxx-16 12:00 for a 31 day month
While this is mathematically correct, it is confusing in plots as the tick labels are inconsistent with the tick locations now, because they print out only the trunctated day without the time. This looks strange sometimes, e.g. plotting global radiation, as sometimes maxima and sometimes minima are on the intersection with the grid.
I think tick labels should always precisely name their location: when showing just the day and no time they should be placed right at midnight.
My patch puts ticks always at midnight of the 15th of each month, which might be questionable but which is the default e.g. in financial applications. I would also be perfectly satisfied if they sit sometimes on the 15th and sometimes on the 16th - as long as one can derive their precise and consistent location from the label.
|
Mon 13 Mar 2017 03:52:15 AM UTC, comment #9:
I pushed a patch for bug #50808 which allows datenum to accept vectors that contain fractional months.
@Lars: Is your patch from this report still necessary? If so, could you give an example of where the current behavior is wrong so I can see how your patch is fixing it?
I'm attaching two png images made with the existing code (after fix for bug #50808) (regular.png) and your proposed patch (patched.png).
One thing I note is that the ticks are unevenly spaced in both versions. That seems strange, but maybe it is just related to the number of days in each month.
Code to reproduce
|
Sun 12 Mar 2017 06:21:51 PM UTC, comment #8:
Yes, the issue is with vectors that contain a mix of leap and non-leap years with fractional months. With Lars' patch from bug #50508 applied
With my patch for #50508
|
Sun 12 Mar 2017 12:49:35 PM UTC, comment #7:
The result in Matlab R2016a:
I got the same with Octave 4.2.1 and default (without any patches).
|
Sat 11 Mar 2017 09:33:51 PM UTC, comment #6:
@Markus: Could you try the following in Matlab? Leap year processing of vectors in Octave is wrong at the moment.
|
Fri 10 Mar 2017 05:18:02 PM UTC, comment #5:
Thanks, Markus. I located the bug in datenum(). I will create a new report for that and submit a patch for it.
That will avoid this crash in datetick(), but I suggest to apply the final patch provided here, too, because it might generate somehow nicer tick positions.
|
Fri 10 Mar 2017 12:46:08 PM UTC, comment #4:
Here the output in Matlab R2016a:
So the month seems to be always rounded down. Year and day on the other hand float.
It might be worth to double check in a more recent version of Matlab whether that rather inconsistent behavior has changed.
|
Fri 10 Mar 2017 12:24:23 PM UTC, comment #3:
I attached an updated patch that fixes it in all calls to datenum() but the real problem might rather be datenum() itself which shows pretty inconsistent behaviour for non integer inputs:
Probably datenum() should be fixed instead as non-integer years and days always work fine. Non-int month also work for a single date but fail for a date array.
For compatibility, could somebody check how Matlab's datenum() behaves for non-integer inputs?
However, the attached updated patch avoids all non-integer datenum() calls in datetick() and sets ticks to more sane positions (midnight,1st of month) than calls for a fixed datenum would (noon, arbitrary day):
(file #39956)
|
Fri 10 Mar 2017 09:59:11 AM UTC, comment #2:
Rik, do not push my changeset yet. Reviewing my fix, I suggest the line
should better read
Otherwise a similar problem may arise in case
does not yield exactly 0.5. Additionally, there are several other locations in datetick() with a similar construct. They should be checked for possible problems, too. I'll have a look at this.
|
Fri 10 Mar 2017 05:02:56 AM UTC, comment #1:
Confirmed. This happens on 4.2.1 as well so the fix should probably go on stable.
|
Wed 08 Mar 2017 12:06:56 PM UTC, original submission:
The datetick command crashes if the date range is between 3 and about 3 1/2 month.
This results from an attempt in datetick to plot ticks in 1/2 month distance and the datenum function won't accept fractional values for the month.
I have attached a patch for datetick.m that fixes this problem:
|