working with times - unclear receiving values
4 次查看(过去 30 天)
显示 更早的评论
Hi,
I'm using Matlab R14SP3.
I'm using datenum and datestr functions to perform my data analysis based on time.
startTime=datenum('23:00:00','HH:MM:SS')-datenum('2022','yyyy')+doy2date(260,2022)
endTime=datenum('0:10:00','HH:MM:SS')-datenum('2022','yyyy')+doy2date(261,2022)
Where doy2date is from matlab fileexchange.
Time=datenum(time,'HH:MM:SS')-datenum('2022','yyyy')+doy2date(YearDay,2022*ones(length(time))
stop_time = find(Time>endTime);
if isempty(stop_time)
stop=length(time);
else
stop=stop_time(1);
When checking with datestr for endTime and Time - I see correct data.
When I check the value of endTime and Time I see that Time value is smaller than endTime
For sure, time (and Time) vectors are ending at 1AM.
Any clues how to solve the issue?
2 个评论
dpb
2022-9-29
编辑:dpb
2022-9-29
Need MWE (minimum working example) to illustrate the problem -- you didn't provide the needed data to run the above -- time and YearDay.
But, there's a least one logic or typo in the above, the code snippet
...+doy2date(YearDay,2022*ones(length(time))
looks to be missing the traling ",1); to create a column vector; as is it would be an array of NxN
Time=datenum(time,'HH:MM:SS')-fix(datenum(time,'HH:MM:SS'))+datenum(2022,0,YearDay);
should do the trick; datenum will expand single value arguments automagically, so should the FEX submission if you're bound and determined to not chuck it over...
One could write the above as simply
startTime=datenum('23:00:00','HH:MM:SS')-datenum('2022','yyyy')+datenum(2022,0,260);
endTime=datenum('0:10:00','HH:MM:SS')-datenum('2022','yyyy')+datenum(2022,0,261);
and remove the dependency upon the external FEX function; that's all it's doing under the hood.
Also, in
...datenum('23:00:00','HH:MM:SS')-datenum('2022','yyyy')...
the use of "2022" in the correction is not robust; the default y,md for datenum when text strings contain only time information is Jan, 1, CURRENTYEAR. The above will work until next year at which time it will be a year off. It would be better to encode a fixed reference year into the first argument or eliminate the need for the fixup in the above manner by saving only the fractional part as
datenum('23:00:00','HH:MM:SS')-fix(datenum('23:00:00','HH:MM:SS'))
which has the performance disadvantage of computing the same datenum value twice; of course, you're calling datenum twice't anyway, both with missing portions of the date/time string which undoubtedly causes at least some extra work internally.
As far as the actual Q?, you're probably seeing the effects of floating point rounding, but without the actual numbers, can't tell that for certain. The new datetime class would undoubtedly make the above go away; unless you're really restricted for other reasons, upgrading would be beneficial.
dpb
2022-9-29
Here's an example of what can go wrong with datenum being just a double...
dn1=datenum(0,0,0,23,0,0)
dn1==23/24 % it's just fractional part of a day
dn2=(datenum('23:00:00','HH:MM:SS')-fix(datenum('23:00:00','HH:MM:SS')));
dn2==dn1 % but it fails here???
dn2-dn1
NB: the size of the difference -- 1E5 X the size of roundoff of a double. That's because the magnitude of the values from which dn2 was computed are full-fledged datenums of the current year and so there's those 5 decimal digits of precision lost in comparison to the direct floating point calculation or use of datenum with an explicit 0 year.
We'll still have to see the actual code and values to see where it went wrong, but that's illustrative that "there be dragons!" in datenum from precision with only the double.
回答(0 个)
另请参阅
类别
在 Help Center 和 File Exchange 中查找有关 Time Series Objects 的更多信息
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!