Benefits of using datenum to convert a date to an equivalent number?

Hi,

I have been handed a MATLAB code that I want to speed up. The function datenum has been used which takes a lot of time. Each file has an array of some 50000 dates and there might be hundreds of such files so it takes up a lot of time. I was wondering if I could skip that step altogether. I do not see a specific need to convert the dates, unless it is faster to pass as a parameter among functions or any such benefit. If I do not need to use the equivalent number in any way, are there any other benefits that one may get by converting dates to equivalent numbers?

Also if I deem it necessary, is there an equivalent function to datenum in C, so that I can use a mex file for the purpose?

Thank you in advance!

I appreciate your advice!

Answer 1

[dpb]

A) If the application never uses the serial date numbers as datenums then it would seem that one could, indeed simply dispense with the conversion. That should be easy enough to check. The only reason I could see for doing the conversion and not using the value would be if were trying to speedup some i/o or reduce the size of an external file--the datenum as a double could be written in a stream (unformatted) file and retrieved faster than the string format of the same date. Of course, that would entail using datestr on the other end for human consumption.

B) A precise duplication of Matlab datenum in C is highly unlikely to exist -- it has great flexibility and a specific reference value that pretty much makes it unique afaik. There are alternative formulations that could, in theory be used, with an offset for the origin. If dates are restricted to those in the relatively short time frame around current, any discrepancies between routines (barring an actual bug, of course) should be minimal. The one advantage of sticking w/ Matlab is that if one uses consistent generation of same then one can rely on comparisons as then rounding will be the same...that might break slightly with mixing two libraries.

Again, whether any of the above is a problem would depend mostly on what is actually being done in the application.

One thing to note would be whether the call to datenum uses the specific format string--that is quite a lot faster than having to go thru the logic to try to automagically parse the input string (assuming string input form, of course). See the doc's for datenum for more on this point.

[abc]

I am not sure I understand your last point. We do mention the format of the date string in the function. This is the function: Date1=datenum(c1,'mm/dd/yyyy HH:MM'); Are you saying there is a way to implement it faster?

[dpb]

No, that is using the specific format. It's the form

dn=datenum(datestring);

w/o the format that is more time-consuming yet (because datestr has to try to guess the format from the input instead of knowing a priori from the input).

Oh, ABTW, after all the input processing datenum calls datenummx a mex-file to do the dirty work so likely won't save a whole lot going that way.

If this is really a bottleneck and can't be eliminated or otherwise resolved, you might consider looking at the existing routine and see if could, given a restricted possible set of inputs for the application, reduce a great deal of the pre-processing before the lower-level call or, perhaps even figure out what would need to call the lower-level routine directly.

Answer 2

[Jan]

Matlab's date conversion functions are very smart and this requires a remarkable delay. If the input formats are exactly defined, a specific C-function can be very much faster. See e.g. FEX: DateStr2Num and FEX: DateConvert.

[dpb]

I've never had so many to do that the time issue was an issue but I recall the comment before.

Wonder why, other than the front end, why once the format is set and all in the front end it should be so that the actual computation would be so comparatively slow? Seems like that should be straightforward after a little front-end overhead.

ADDENDUM:

Or, after reading the FEx comment, is it that DateNum does the string checking on every operation rather than just once on the first element (as I had presumed), perhaps?

ADDENDUM 2:

OK, datenum is doing it's utmost on every conversion; not always what one would hope but clearly why it's not a speed demon--

>> datestr(datenum(['12/31/2006';'31/12/2006']))
ans =
31-Dec-2006
12-Jul-2008
>> datestr(datenum(['31/12/2006';'12/31/2006';]))
ans =
28-May-0037
31-Dec-2006
>>

Creative if nothing else... :)