From: "Steven_Lord" <>
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$>
References: <> <hsenni$h02$> <ir1j1l$ese$>
Mime-Version: 1.0
Content-Type: text/plain;
Content-Transfer-Encoding: 7bit
X-Trace: 1305814450 29039 (19 May 2011 14:14:10 GMT)
NNTP-Posting-Date: Thu, 19 May 2011 14:14:10 +0000 (UTC)
In-Reply-To: <ir1j1l$ese$>
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: comp.soft-sys.matlab:727690

"Roger Stafford" <> wrote in 
message news:ir1j1l$ese$
> "Steven Lord" <> wrote in message 
> <hsenni$h02$>...
>> "radar" <> wrote in message 
>> >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
>> comp.soft-sys.matlab (CSSM) 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');

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:
> 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
To contact Technical Support use the Contact Us link on