bugGNU Octave - Bugs: bug #50493, datetick crashes on certain date...

 
 

bug #50493: datetick crashes on certain date ranges

Submitted by:  Lars Kindermann <larskindermann>
Submitted on:  Wed 08 Mar 2017 12:06:56 PM UTC  
 
Category: PlottingSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Unexpected Error
Status: FixedAssigned to: None
Originator Name: Open/Closed: Closed
Release: devOperating System: Any

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

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.

Rik <rik5>
Project Administrator
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)

Lars Kindermann <larskindermann>
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.

Lars Kindermann <larskindermann>
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

Rik <rik5>
Project Administrator
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

Rik <rik5>
Project Administrator
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).

Markus Mützel <mmuetzel>
Project Member
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.

Rik <rik5>
Project Administrator
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.

Lars Kindermann <larskindermann>
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.

Markus Mützel <mmuetzel>
Project Member
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)

Lars Kindermann <larskindermann>
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.

Lars Kindermann <larskindermann>
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.

Rik <rik5>
Project Administrator
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:

Lars Kindermann <larskindermann>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #40016:  example.png added by larskindermann (17KiB - image/png - Example of the problem)
file #39986:  regular.png added by rik5 (16KiB - image/png)
file #39987:  patched.png added by rik5 (15KiB - image/png)
file #39956:  datetickV2.diff added by larskindermann (1KiB - text/x-patch - Updated patch)
file #39939:  datetick.diff added by larskindermann (1KiB - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by mmuetzel (Posted a comment)
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by larskindermann (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 8 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 16 Mar 2017 04:30:33 PM UTCrik5StatusPatch Submitted=>Fixed
      Open/ClosedOpen=>Closed
    Thu 16 Mar 2017 02:30:27 PM UTClarskindermannAttached File-=>Added example.png, #40016
    Mon 13 Mar 2017 03:53:22 AM UTCrik5Attached File-=>Added regular.png, #39986
      Attached File-=>Added patched.png, #39987
    Fri 10 Mar 2017 12:24:23 PM UTClarskindermannAttached File-=>Added datetickV2.diff, #39956
    Fri 10 Mar 2017 05:02:56 AM UTCrik5StatusNone=>Patch Submitted
    Wed 08 Mar 2017 12:06:56 PM UTClarskindermannAttached File-=>Added datetick.diff, #39939

    Back to the top


    Powered by Savane 3.1-cleanup1