[Octave-bug-tracker] [bug #59979] Unexpected format for output from datevec

[Philip Nienhuis]

Update of bug #59979 (project octave):

              Item Group:          WTF, Matlab?!? => Inaccurate Result      
                  Status:                    None => Confirmed              

    _______________________________________________________

Follow-up Comment #11:

PMFJI
I quite agree with comment #2 and comment #5 as regards "formatted display"
and representation.
Yet I wouldn't rely too much on Matlab as a reference as that occasionally
gets it wrong as well; e.g., I recently hit this with patch #9953 (see midway
comment #10) where Matlab screws up with coordinates display:
> ... for -181.7: while <Matlab> gets the total right as it returns <degrees>
41' 60", it should of course round to 42' 00" ...
...and I've regularly hit similar issues as the OP in both Matlab and Octave
in my tidal analysis project. (generally Matlab seems to do better, though.)

My conclusion was (and is) that representation and "formatted display" is
unavoidably prone to rounding error here and there, and working around that
requires special care on a case-by-case basis.
I suppose this supports Tasos' stance in comment #9.

@comment #6:
I'm only vaguely familiar with IEEE number representations, but AFAIK floating
point machine precision depends on number magnitude. 'dec2bin (datenum (2021,
1, 27))' gives '10110100001110000111', parts of which probably get morphed
into the exponent part, but either way you loose precision with larger
numbers.
So your question depends on what date range you have in mind.

Getting better accuracy when working with dates starts with subtracting the
start date from your period of interest (comment #1: datenum (2021,1,27) =
738183), work with those numbers, and at the end add it back, as then you'll
have a much better resolution to start with.
Just to show this, compare Markus' example output in comment #7 with this:

>> format long
>> a = datenum ([0, 0, 0, 17, 0, 0]);
>> b = datenum ([0, 0, 0, 16, 40, 0]);
>> datevec (a - b)
ans =
 Columns 1 through 3:
  -1.000000000000000e+00   1.200000000000000e+01   3.100000000000000e+01
 Columns 4 through 6:
                       0   1.900000000000000e+01   5.999999999999591e+01

>> format short
>> datevec (a - b)
ans =
   -1.0000   12.0000   31.0000         0   19.0000   60.0000


to see that 
* accuracy gets quite a bit better for dates close to Octave's and Matlab's
epoch, but 
* Octave's rounding in datevec could be better. Matlab gives:

>> a = datenum ([0, 0, 0, 17, 0, 0]);
>> b = datenum ([0, 0, 0, 16, 40, 0]);
>> format long
>> datevec (a-b)
ans =
     0     0     0     0    20     0
>> format short
>> datevec (a-b)
ans =
     0     0     0     0    20     0


IMO "Item group" should be "Inaccurate Result" rather than "WTF, Matlab?!?",
and "Status" should be "confirmed".
Setting field accordingly.



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?59979>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/