From: "Sung Soo Kim" <>
Newsgroups: comp.soft-sys.matlab
Subject: Re: Very weird resolution issue. Bug ????? Seriously !!
Date: Thu, 5 Mar 2009 05:29:02 +0000 (UTC)
Organization: JHU
Lines: 43
Message-ID: <gonnuu$krq$>
References: <goju5b$nv4$> <>
Reply-To: "Sung Soo Kim" <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Trace: 1236230942 21370 (5 Mar 2009 05:29:02 GMT)
NNTP-Posting-Date: Thu, 5 Mar 2009 05:29:02 +0000 (UTC)
X-Newsreader: MATLAB Central Newsreader 1724905
Xref: comp.soft-sys.matlab:522632

Hi Peter,
I'm a little overwhelmed by the length of your response. Thanks anyway.

> This is exactly about that.  Even in C, you can't ensure perfect
> consistency, because a different compiler, or a different compiler
> RELEASE, or a different architecture, may generate code that still
> follows the C standard, but produces slightly different results, because
> of the above.

I know that. I don't expect consistency across compiler versions or across machines or even across different settings. What I said in consistency is if I use the same compiler, same machine, same language, then I have to get the same result. That's why we use computer. I said I was using one machine. Unfortunately, my example shows that my expectation on MATLAB was technically wrong. I ADMIT IT. Even in one machine, one Matlab version, super simple matrix that 'might' be assumed to produce the same result in many sense can produce different results. That means that my definition of consistency cannot be generalized to MATLAB. That may be my fault.

Your example of Monte Carlo simulation is I think a bit out of focus on this topic (from my point of view). You know that if we start from the same seed number in the same machine using the same matlab version with the same random number generator, then the simulation result is always the same, and it must be. If not, there is something wrong. The random is not really random in computer. Computer is expected to do what is expected. Even when there is hardware malfunction, that malfunction should repeat unless something physically weird happens like overheating. If not, we're not dealing with deterministic machine, and we cannot rely on that. We cannot believe the result of Monte Carlo simulation on that machine either. This expectation is fair, period, and this kind of consistency is really heart of computing or scientific software, though physical world is not perfect and any weird 
thing can happen. (This is another issue but I think, given the same 32bit seed, the random number generator is supposed to generate the same 32bit random number sequence across platform and across machine whatever if the version number of the random number generator is the same in MATLAB. If not, correct me. ) 

> This does not make C programs useless for science.  You just have to
> understand the constraints and limitations when you draw your
> conclusions, just like with any other scientific tool.

Following the spec is very important though it may not be an issue on most cases. In C/C++, 'a+b' is defined to add b to a, not add a to b. So if the compiler follows this spec, a+b+c must be always equal to (a+b)+c, not a+(b+c) in any machine no matter what the precision is (I'm not saying cross platforms or cross compilers versions or cross vendors. I'm saying 'in a single executable'.). If it is not, we call it a bug, or it must be documented for future fix. If not documented either, we say it is not a standard compatible compiler. Is this unfair? Surely the standard or spec may change in the future, and I understand that there are many kinds of constraints and limitations. But that's a different problem from consistency I said. If it gives me a+(b+c) occasionally, do you want to use that compiler? (Hm.. maybe I would if it gives me much faster executables than other standard 
compilers... But I would expect documentation. ;) ) 

In MATLAB, I found today that 'a+b' IS documented and defined as 'addition of a and b'... Sigh... Well... I didn't know that MATLAB's definition is less clear than C/C++ in technical sense. Shame on me... Sigh again... I think this was the start of my surprise on the examples I gave. In MATLAB, no precise way of addition is defined. That said, my complain was 'technically' unfair. Any floating point error can happen. There was nothing wrong.

> But my point is, running the same code in the same version of MATLAB on
> a different platform might also produce different results.

Well, I know this very very well. I said several times in previous replies... I'm talking about the same machine, the same version, and 'supposedly the same codes', though the last bit is not guaranteed.

But, whatever... It doesn't matter anymore... MATLAB's spec of '+' is not what I guessed.

> There's no "quiet changing" going on.  If you'd like documentation on what not to
> expect from floating point, well, read the papers that have been
> suggested to you.  
> What we're all trying to say is that there is no change of technical
> behavior.  Floating point computations still come with round-off error.
> You still should not rely on exact answers from floating point values.
> That's not a change.

Right. That's not a change. They've not changed their spec on '+'. So any floating point rounding error can happen anytime anywhere. Mathworks has the whole right to change the order of addition as they want. That said, matrix multiplication is out of question.

Hm... I think I'm pretty much well convinced by all of you guys.