"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
>> (z1) % in exact arithmetic, would be 0
>> minute = (1/1440);
>> z2 = 0;
>> for k = 1:1440
>> z2 = z2+minute;
>> end
>> (z21) % 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.softsys.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 roundoff 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
