Path: news.mathworks.com!newsfeed-00.mathworks.com!newsfeed2.dallas1.level3.net!news.level3.com!postnews.google.com!p15g2000vbl.googlegroups.com!not-for-mail
From: Rune Allnor <allnor@tele.ntnu.no>
Newsgroups: comp.soft-sys.matlab
Subject: Re: Is it a bug or what is it?
Date: Thu, 24 Sep 2009 04:25:17 -0700 (PDT)
Organization: http://groups.google.com
Lines: 44
Message-ID: <1a3ac847-4787-4ec6-9c54-cb276ec67013@p15g2000vbl.googlegroups.com>
References: <h9f9u0$elc$1@fred.mathworks.com> <h9fbau$qer$1@fred.mathworks.com>
NNTP-Posting-Host: 77.17.154.153
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Trace: posting.google.com 1253791517 24814 127.0.0.1 (24 Sep 2009 11:25:17 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Thu, 24 Sep 2009 11:25:17 +0000 (UTC)
Complaints-To: groups-abuse@google.com
Injection-Info: p15g2000vbl.googlegroups.com; posting-host=77.17.154.153; 
	posting-account=VAp5gAkAAAAmkCze5hvZtMeedpZWNthI
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; 
	Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; 
	.NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET CLR 1.1.4322),gzip(gfe),gzip(gfe)
Xref: news.mathworks.com comp.soft-sys.matlab:572565

On 24 Sep, 10:41, "Bruno Luong" <b.lu...@fogale.findmycountry> wrote:
> "Victor kasaksha" <vi...@mail.ru> wrote in message <h9f9u0$el...@fred.mathworks.com>...
> > I have following trouble:
>
> > A = rand(1000); B = rand(1000); maxnumcompthreads(1); C1 = A*B; maxnumcompthreads(2); C2 = A*B; spy((C1 == C2))
>
> > why are the two matrices different in the second part?  
>
> Yes, this is due to the operation orders that are different on the number of thread:http://www.mathworks.com/support/bugreports/532399
>
> Matlab 2009B has corrected this inconsistency behavior (from my test; monothread calculation is forced to behave like multi-thread). Note that the calculation is not compatible with older Matlab version, but at least is consistent within itself.

I'm not sure I would have accepted that point as a 'bug'.

First of all, floating-point arithmetics is inexact. Errors
do occur, and are implementation dependent.

Second, ensuring that things are done one particular raises
the question wheher there exists one order of operations that
is somehow 'optimal' or 'best'. And for matrix-vector product
Ab = c the answer is 'yes', there is:

1) Compute the element-vise products p(i) = a(i,j)*b(i)
2) Sort the vector of products p(i)
3) Sum the sorted p in either descending or ascending order

Will it be considered a 'bug' if things are done in other
ways than this? If 'no' - why?

Third, if it is a goal to ensure that things are done in one
particular order in the parallel implementation, then the
problem statement is. by definition, no longer parallelizable
and the savings by using a parallel implementation are lost.

I think this might be one of the cases where the cure does
more damage than the disease.

Rune