From: "Sung Soo Kim" <>
Newsgroups: comp.soft-sys.matlab
Subject: Re: Very weird resolution issue. Bug ????? Seriously !!
Date: Tue, 3 Mar 2009 20:54:03 +0000 (UTC)
Organization: JHU
Lines: 32
Message-ID: <gok5db$mqi$>
References: <goju5b$nv4$> <gok3qm$2gn$>
Reply-To: "Sung Soo Kim" <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Trace: 1236113643 23378 (3 Mar 2009 20:54:03 GMT)
NNTP-Posting-Date: Tue, 3 Mar 2009 20:54:03 +0000 (UTC)
X-Newsreader: MATLAB Central Newsreader 1724905
Xref: comp.soft-sys.matlab:522230

Thanks Roger, 
Your example is cool.
So, the oder of addition and subtraction does matter.

But still... why MATLAB changed the order of calculation from what it is suppsed to be? I didn't mean to change the order of calculation in my example. My example should give the same result not only in theoretical sense but also in engineering sense.

What algorithm should I depend on then??? Is the Matlab's matrix multiplication algorithm standard???

As I said, it was not a problem in earlier version of Matlab (R14), which I can depend on. (Please don't say me to go back to that old version. I already changed a lot of my codes and it is painful to return, though I'm already in pain testing my previously perfect library.)

Anyway, is this algorithm documented??

I have to reform my question as: How can I predict my result based on obvious standard??


"Roger Stafford" <> wrote in message <gok3qm$2gn$>...
> "Sung Soo Kim" <> wrote in message <goju5b$nv4$>...
> > ........
> > isequal(c, b(1,1))  % This must be '1' because c should be equal to b(1,1)
> > ........
>   Sung Soo Kim, in expecting that c and b(1,1) will be exactly equal you are not taking into account that differing round-off errors in digital computers can make even the associative law of addition or multiplication fail.  That is, (a+b)+c and a+(b+c) can be different down at the least bit level.  That being the case, you have no reason to assume that c and b(1,1) will be exactly equal if their operations happen to have been performed in a different order.  In general, when dealing with floating point numbers on digital computers one should not expect results that are theoretically equal to actually be equal when arrived at by different computational procedures.
>   Try this on your computer:
>  3/14+(3/14+15/14) == (3/14+3/14)+15/14
> If you use IEEE 754 double precision binary floating point numbers, as does Matlab, these results must be unequal if the rules of rounding-to-nearest are faithfully carried out.  Try doing some binary arithmetic like this by hand and you will soon see why.
> Roger Stafford