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