Path: news.mathworks.com!not-for-mail From: "Steven_Lord" <slord@mathworks.com> Newsgroups: comp.soft-sys.matlab Subject: Re: addtodate bug? Date: Thu, 19 May 2011 10:14:10 -0400 Organization: MathWorks Lines: 106 Message-ID: <ir38ji$sbf$1@newscl01ah.mathworks.com> References: <926292603.124109.1273679295245.JavaMail.root@gallium.mathforum.org> <hsenni$h02$1@fred.mathworks.com> <ir1j1l$ese$1@newscl01ah.mathworks.com> NNTP-Posting-Host: ah-slord.dhcp.mathworks.com Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Trace: newscl01ah.mathworks.com 1305814450 29039 172.31.44.225 (19 May 2011 14:14:10 GMT) X-Complaints-To: news@mathworks.com NNTP-Posting-Date: Thu, 19 May 2011 14:14:10 +0000 (UTC) In-Reply-To: <ir1j1l$ese$1@newscl01ah.mathworks.com> X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Newsreader: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 Xref: news.mathworks.com comp.soft-sys.matlab:727690 "Roger Stafford" <ellieandrogerxyzzy@mindspring.com.invalid> wrote in message news:ir1j1l$ese$1@newscl01ah.mathworks.com... > "Steven Lord" <slord@mathworks.com> wrote in message > <hsenni$h02$1@fred.mathworks.com>... >> >> "radar" <able@tds.net> wrote in message >> news:926292603.124109.1273679295245.JavaMail.root@gallium.mathforum.org... >> >I don't see why the output of this code should change as shown below. >> >> Since a change of 1 in a serial date number represents the passage of a >> day, (1/86400) would represent the passage of a second and (1/1440) would >> represent the passage of a minute. However, neither of those numbers can >> be exactly represented in double precision, so: >> >> second = (1/86400); >> z = 0; >> for k = 1:86400 >> z = z+second; >> end >> (z-1) % in exact arithmetic, would be 0 >> minute = (1/1440); >> z2 = 0; >> for k = 1:1440 >> z2 = z2+minute; >> end >> (z2-1) % in exact arithmetic, would be 0 >> >> Neither z1 nor z2 are exactly 1, are they? This behavior is NOT, repeat >> NOT a bug. >> >> See Q6.1 in the newsgroup FAQ and in particular the bottom of the first >> column of page 2 of the Cleve's Corner article linked in that question. >> -- >> Steve Lord >> slord@mathworks.com >> comp.soft-sys.matlab (CSSM) FAQ: >> http://matlabwiki.mathworks.com/MATLAB_FAQ > - - - - - - - - - - > Hi Steve. I know a year has passed since this thread was first > introduced, but I can't resist a mild objection to your response to this > query. > > You stated in defense of 'addtodate' that in adding a minute to the > serial date number it could not avoid a cumulative error due to the > inability of representing 1/1440 as a precise binary floating point > number, and of course it is indeed true that such fractions cannot be so > represented. However, that doesn't prevent 'addtodate' from making an > appropriate correction to each of its outputs so that such an error > wouldn't accumulate. It need only correct each tentative serial date > number output by multiplying it by 86400000, performing a 'round' to the > nearest integer, and then dividing by that same quantity. This would > ensure that each output of 'addtodate' was always the nearest possible > 'double' fractional value in terms of days to an equivalent integral > multiple of milliseconds, which is apparently not the case at present. > Such an elementary correction would make 'addtodate' immune from such > cumulative errors almost to the years 300000 AD or BC before encountering > the 'realmax' limitation. That's a possibility; I can pass that suggestion on to the developers responsible for ADDTODATE. If I wanted to determine the time multiple minutes from a specified time, I would call ADDTODATE _once_ adding the whole span rather than calling it multiple times with intervals of one minute each. t = now; t1 = addtodate(t, 10, 'minute'); t2 = t; for k = 1:10 t2 = addtodate(t2, 1, 'minute'); end If I needed an array of values representing times spaced at one minute intervals, I'd probably use DATEVEC and DATENUM. t = now; V = datevec(t); M = repmat(V, 11, 1); M(:, 5) = M(:, 5)+(0:10).'; t1 = datenum(M) > In the words of the famous quip, "it's not a bug - it's a feature", this > is admittedly a "feature", but it is a feature that in my opinion > Mathworks should seriously consider improving. > > I should add that what brought this to my attention was yesterday's > unanswered thread "addtodate irreversible behavior" by Le Fou Volant at: > > http://www.mathworks.nl/matlabcentral/newsreader/view_thread/307921 > > This problem may involve some kind of round-off errors (though I haven't > figured out what they might be) and deserves an answer from someone at > Mathworks. I've forwarded that thread to the developers responsible for ADDTODATE as well. I don't know when or if they will respond in that thread. I posted a message to that effect in that thread. -- Steve Lord slord@mathworks.com To contact Technical Support use the Contact Us link on http://www.mathworks.com