DATENUM(x, 30)
in [Matlab]
|
Prev: spmd help
Next: LIBSVM and Visual Studio 2010
From: Matt Fig on 30 Jun 2010 10:49 Here is the relevant line from the documentation for DATENUM: N = datenum(S, F) converts one or more date strings S to serial date numbers N using format string F to interpret each date string. .... See the datestr reference page to find valid string values for F. These values are listed in Table 1 in the column labeled "Dateform String." It is the reference to the column label which I missed before. Otherwise it does seem intuitive that both functions should have access to the Dateform Number convention as well as the Dateform String.
From: Jan Simon on 1 Jul 2010 06:14 Dear Matt Fig, > Here is the relevant line from the documentation for DATENUM: > > N = datenum(S, F) converts one or more date strings S to serial date numbers N using > format *string* F ... > > Otherwise it does seem intuitive that both functions should have access to the Dateform Number convention as well as the Dateform String. The hypothetical intuitive DATENUM(x, 31) suffers from the same incomplete definition of years using 2 digits as the old Y2K problem. The artifical need of a pivot year is caused by some programmers, who wanted or needed to save 2 bytes in the early 70th or the last century. But before I ask these programmers to come forward and excuse themselves for the current inconveniences of DATENUM, I admit, that my DateStr2Num published in the FEX cannot handle dates with more than 4 digits. In 9999 the FEX users will condemn me for this limitation, while I'm sure, that TMW will expand DATENUM for this case - and make it slower again. I'd be the last who asks TMW to reduce backward compatibility! DATESTR, DATENUM, DATEVEC are so powerful and intelligent, that they are surprisingly slow. The much simpler and faster MEX functions DATENUMMX and DATEVECMX are shipped with the toolboxes and it would be very nice, if TMW would document them - and use them consequently. E.g. the command NOW would be much faster, if it calls DATENUMMX instead of DATENUM (checked until 2009a only). In consequence, I'm using DATESTR and DATENUM to parse user inputs only to care for invalid formats, while all operation on already validated dates are performed by simpler and 25 to 100 times faster M- and Mex-functions (see DateConvert and DateStr2Num on the FEX). Kind regards, Jan
From: us on 1 Jul 2010 06:43 "Jan Simon" <matlab.THIS_YEAR(a)nMINUSsimon.de> wrote in message <i0hppc$mvh$1(a)fred.mathworks.com>... > Dear Matt Fig, > > > Here is the relevant line from the documentation for DATENUM: > > > > N = datenum(S, F) converts one or more date strings S to serial date numbers N using > > format *string* F ... > > > > Otherwise it does seem intuitive that both functions should have access to the Dateform Number convention as well as the Dateform String. > > The hypothetical intuitive DATENUM(x, 31) suffers from the same incomplete definition of years using 2 digits as the old Y2K problem. The artifical need of a pivot year is caused by some programmers, who wanted or needed to save 2 bytes in the early 70th or the last century. > > But before I ask these programmers to come forward and excuse themselves for the current inconveniences of DATENUM, I admit, that my DateStr2Num published in the FEX cannot handle dates with more than 4 digits. In 9999 the FEX users will condemn me for this limitation, while I'm sure, that TMW will expand DATENUM for this case - and make it slower again. I'd be the last who asks TMW to reduce backward compatibility! > > DATESTR, DATENUM, DATEVEC are so powerful and intelligent, that they are surprisingly slow. The much simpler and faster MEX functions DATENUMMX and DATEVECMX are shipped with the toolboxes and it would be very nice, if TMW would document them - and use them consequently. E.g. the command NOW would be much faster, if it calls DATENUMMX instead of DATENUM (checked until 2009a only). > > In consequence, I'm using DATESTR and DATENUM to parse user inputs only to care for invalid formats, while all operation on already validated dates are performed by simpler and 25 to 100 times faster M- and Mex-functions (see DateConvert and DateStr2Num on the FEX). > > Kind regards, Jan that's why we've overloaded these functions for years... us
From: Jan Simon on 1 Jul 2010 06:55
Dear us, > > But before I ask these programmers to come forward and excuse themselves for the current inconveniences of DATENUM, .... > > DATESTR, DATENUM, DATEVEC are so powerful and intelligent, that they are surprisingly slow. > that's why we've overloaded these functions for years... I'm not sure if your reply concerns the 1st or 2nd statement. ;-) Could I dare to ask you for sharing your overloaded functions - either in the FEX or even better inside the Matlab toolboxes? It was at least worth to ask. Wasting computing time is equivalent to wasting petroleum, e.g. by pouring it into the sea. Kind regards, Jan |