Thread Subject:

Is it a bug or what is it?

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?

Thank you all
Viktor

-------------------------------------------------------------------------------------
MATLAB Version 7.8.0.347 (R2009a)
MATLAB License Number: 46423
Operating System: Linux 2.6.27.29-0.1-pae #1 SMP 2009-08-15 17:53:59 +0200 i686
Java VM Version: Java 1.6.0_04-b12 with Sun Microsystems Inc. Java HotSpot(TM) Client VM mixed mode
-------------------------------------------------------------------------------------
MATLAB Version 7.8 (R2009a)
Simulink Version 7.3 (R2009a)
Bioinformatics Toolbox Version 3.3 (R2009a)
Communications Blockset Version 4.2 (R2009a)
Communications Toolbox Version 4.3 (R2009a)
Control System Toolbox Version 8.3 (R2009a)
Conversion to SeDuMi Version routines for reading in problems from SDPPack,
Curve Fitting Toolbox Version 2.0 (R2009a)
Fixed-Point Toolbox Version 2.4 (R2009a)
Fuzzy Logic Toolbox Version 2.2.9 (R2009a)
Genetic Algorithm and Direct Search Toolbox Version 2.4.1 (R2009a)
INTLAB INTerval LABoratory Version 5.5 07-May-2008 780 files, 690 m-files, 25,517 lines of Matlab
Image Processing Toolbox Version 6.3 (R2009a)
Instrument Control Toolbox Version 2.8 (R2009a)
MATLAB Builder JA Version 2.0.3 (R2009a)
MATLAB Compiler Version 4.10 (R2009a)
Mapping Toolbox Version 2.7.2 (R2009a)
Model Predictive Control Toolbox Version 3.1 (R2009a)
Neural Network Toolbox Version 6.0.2 (R2009a)
Optimization Toolbox Version 4.2 (R2009a)
Parallel Computing Toolbox Version 4.1 (R2009a)
Partial Differential Equation Toolbox Version 1.0.14 (R2009a)
RF Blockset Version 2.4 (R2009a)
RF Toolbox Version 2.5 (R2009a)
Real-Time Workshop Version 7.3 (R2009a)
Real-Time Workshop Embedded Coder Version 5.3 (R2009a)
Regularization Tools Version 4.0
Robust Control Toolbox Version 3.3.3 (R2009a)
Signal Processing Blockset Version 6.9 (R2009a)
Signal Processing Toolbox Version 6.11 (R2009a)
SimElectronics Version 1.2 (R2009a)
SimMechanics Version 3.1 (R2009a)
SimPowerSystems Version 5.1 (R2009a)
Simscape Version 3.1 (R2009a)
Simulink Control Design Version 2.5 (R2009a)
Simulink Design Optimization Version 1.0 (R2009a)
Simulink Fixed Point Version 6.1 (R2009a)
Spline Toolbox Version 3.3.6 (R2009a)
Stateflow Version 7.3 (R2009a)
Stateflow Coder Version 7.3 (R2009a)
Statistics Toolbox Version 7.1 (R2009a)
Symbolic Math Toolbox Version 5.2 (R2009a)
System Identification Toolbox Version 7.3 (R2009a)
Video and Image Processing Blockset Version 2.7 (R2009a)
Wavelet Toolbox Version 4.4 (R2009a)
>>

On 24 Sep, 10:17, "Victor kasaksha" <vi...@mail.ru> wrote:
> I have following trouble:
>
> A = rand(1000); B = rand(1000); maxnumcompthreads(1); C1 = A*B; maxnumcompthreads(2); C2 = A*B; spy((C1 == C2))

Depending on how large the differences are, one possible
non-bug explanation for discrepancies is that the algorthms
do their computations in different orders.

As was discussed here not too long ago, the order in which
one adds numbers represented by inexact floating point formats
might have an impact on the magnitude of the error in the
end result:

>> v = rand(1000,1);
>> V = sort(v);
>> s = sum(v);
>> S = sum(V);
>> s-S % Should equal 0

ans =

 -1.7053e-013

In a matrix-vector multiplication, all the threads need
access to the vector. It might be that the two threads
access the variables in non-obvious ways to minimize the
chance of race conditions or deadlocks.

Rune

"Victor kasaksha" <viphe@mail.ru> wrote in message <h9f9u0$elc$1@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.

Bruno

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

With R2009b it is more curious. If you for example multiply two (200x2000) random matrices with one computational thread and then the same two matrices with two comp. threads you will get two different products and they are !!! different in the third digit !!! So it is obvious that there is something wrong. From numerical viewpoint it is not possible that there arise such differences because of summation order. (third digit different!!! --> All our computations are wrong)

(in above this are two 2000x2000 matrices, sorry)

"Victor kasaksha" <viphe@mail.ru> wrote in message <h9hrk6$plp$1@fred.mathworks.com>...
> With R2009b it is more curious. If you for example multiply two (200x2000) random matrices with one computational thread and then the same two matrices with two comp. threads you will get two different products and they are !!! different in the third digit !!!

Work fine for me (2009B, Vista 64):

A=rand(2000,2000);
B=rand(2000,2000);
n=maxnumcompthreads(1);
C1=A*B;
maxnumcompthreads(2);
C2=A*B;
maxnumcompthreads(n);
isequal(C1,C2) % <- 1

Bruno

"Bruno Luong" <b.luong@fogale.findmycountry> wrote in message <h9hs6v$46e$1@fred.mathworks.com>...
> "Victor kasaksha" <viphe@mail.ru> wrote in message <h9hrk6$plp$1@fred.mathworks.com>...
> > With R2009b it is more curious. If you for example multiply two (200x2000) random matrices with one computational thread and then the same two matrices with two comp. threads you will get two different products and they are !!! different in the third digit !!!
>
> Work fine for me (2009B, Vista 64):
>
> A=rand(2000,2000);
> B=rand(2000,2000);
> n=maxnumcompthreads(1);
> C1=A*B;
> maxnumcompthreads(2);
> C2=A*B;
> maxnumcompthreads(n);
> isequal(C1,C2) % <- 1
>
> Bruno

for my system. Suse Linux 32 Bit, 2009b

>> A=rand(2000,2000);
B=rand(2000,2000);
n=maxnumcompthreads(1);
C1=A*B;
maxnumcompthreads(2);
C2=A*B;
maxnumcompthreads(n);
isequal(C1,C2)
ans =
     0

"Bruno Luong" <b.luong@fogale.findmycountry> wrote in message <h9hs6v$46e$1@fred.mathworks.com>...
> "Victor kasaksha" <viphe@mail.ru> wrote in message <h9hrk6$plp$1@fred.mathworks.com>...
> > With R2009b it is more curious. If you for example multiply two (200x2000) random matrices with one computational thread and then the same two matrices with two comp. threads you will get two different products and they are !!! different in the third digit !!!
>
> Work fine for me (2009B, Vista 64):
>
> A=rand(2000,2000);
> B=rand(2000,2000);
> n=maxnumcompthreads(1);
> C1=A*B;
> maxnumcompthreads(2);
> C2=A*B;
> maxnumcompthreads(n);
> isequal(C1,C2) % <- 1
>
> Bruno

and more:
>> C1(50,50)
ans =
  502.6851
>> C2(50,50)
ans =
  498.3026
>>
It is very very curious !!!

O.K. now a windows Sysem:

-------------------------------------------------------------------------------------
MATLAB Version 7.9.0.529 (R2009b)
MATLAB License Number: 46423
Operating System: Microsoft Windows Vista Version 6.1 (Build 7600)
Java VM Version: Java 1.6.0_12-b04 with Sun Microsystems Inc. Java HotSpot(TM) Client VM mixed mode
-------------------------------------------------------------------------------------


A = rand(2000);
B = rand(2000);
maxnumcompthreads(1)
C1 = A*B;
maxnumcompthreads(2)
C2 = A*B;
isequal(C1,C2)

ans =
     0

and more:

>> C1(500,500)
ans =
  474.6958
>> C2(500,500)
ans =
  475.3501

and this is evil !!!

>
> >> C1(500,500)
> ans =
> 474.6958
> >> C2(500,500)
> ans =
> 475.3501
>

What value do you get for:

A(500,:)*B(:,500)

Bruno

"Bruno Luong" <b.luong@fogale.findmycountry> wrote in message <h9hvfg$16$1@fred.mathworks.com>...
>
> >
> > >> C1(500,500)
> > ans =
> > 474.6958
> > >> C2(500,500)
> > ans =
> > 475.3501
> >
>
> What value do you get for:
>
> A(500,:)*B(:,500)
>
> Bruno

O.K. again:

>> A = rand(2000);
B = rand(2000);
maxnumcompthreads(1);
C1 = A*B;
maxnumcompthreads(2);
C2 = A*B;
isequal(C1,C2)
C1(500,500)
C2(500,500)
ans =
     0
ans =
  509.2091
ans =
  507.8290
>> A(500,:)*B(:,500)
ans =
  507.8290

On 25 Sep, 10:55, "Victor kasaksha" <vi...@mail.ru> wrote:
> "Bruno Luong" <b.lu...@fogale.findmycountry> wrote in message <h9hvfg$1...@fred.mathworks.com>...
>
> > > >> C1(500,500)
> > > ans =
> > >   474.6958
> > > >> C2(500,500)
> > > ans =
> > >   475.3501
>
> > What value do you get for:
>
> > A(500,:)*B(:,500)
>
> > Bruno
>
> O.K. again:
>
> >> A = rand(2000);
>
> B = rand(2000);
> maxnumcompthreads(1);
> C1 = A*B;
> maxnumcompthreads(2);
> C2 = A*B;
> isequal(C1,C2)
> C1(500,500)
> C2(500,500)
> ans =
>      0
> ans =
>   509.2091
> ans =
>   507.8290>> A(500,:)*B(:,500)
>
> ans =
>   507.8290

Seems to be a bug somewhere. I'd sen this example
to mathworks tech support.

Rune

On 25 Sep, 11:04, Rune Allnor <all...@tele.ntnu.no> wrote:
> On 25 Sep, 10:55, "Victor kasaksha" <vi...@mail.ru> wrote:
>
>
>
>
>
> > "Bruno Luong" <b.lu...@fogale.findmycountry> wrote in message <h9hvfg$1...@fred.mathworks.com>...
>
> > > > >> C1(500,500)
> > > > ans =
> > > >   474.6958
> > > > >> C2(500,500)
> > > > ans =
> > > >   475.3501
>
> > > What value do you get for:
>
> > > A(500,:)*B(:,500)
>
> > > Bruno
>
> > O.K. again:
>
> > >> A = rand(2000);
>
> > B = rand(2000);
> > maxnumcompthreads(1);
> > C1 = A*B;
> > maxnumcompthreads(2);
> > C2 = A*B;
> > isequal(C1,C2)
> > C1(500,500)
> > C2(500,500)
> > ans =
> >      0
> > ans =
> >   509.2091
> > ans =
> >   507.8290>> A(500,:)*B(:,500)
>
> > ans =
> >   507.8290
>
> Seems to be a bug somewhere. I'd sen this example
> to mathworks tech support.

...which means "I would have sent this example to TMW
if I were you."

Just to avoid any misunderstanding: You should report
this example to TMW as a bug.

Rune

> >> C1(500,500)
> ans =
> 474.6958
> >> C2(500,500)
> ans =
> 475.3501
>
> and this is evil !!!

Very evil!

On 64bit 2009b Linux, all matrices are identical, up to 8 threads.

You say you have a 32 bit machine, maybe the problem is in the 32 bit BLAS. Anyone else with a multicore 32 bit system and 2009b here?

If you only have single core, try setting maxNumCompThreads(2) anyway.

Work also fine on XP 32 Intel Core 2 Duo. So I don't know what's up with your computer.

> Work fine for me (2009B, Vista 64):
>
> A=rand(2000,2000);
> B=rand(2000,2000);
> n=maxnumcompthreads(1);
> C1=A*B;
> maxnumcompthreads(2);
> C2=A*B;
> maxnumcompthreads(n);
> isequal(C1,C2) % <- 1
>
> Bruno

Bruno

"Bruno Luong" <b.luong@fogale.findmycountry> wrote in message <h9iaad$p3i$1@fred.mathworks.com>...
> Work also fine on XP 32 Intel Core 2 Duo. So I don't know what's up with your computer.
>
> > Work fine for me (2009B, Vista 64):
> >
> > A=rand(2000,2000);
> > B=rand(2000,2000);
> > n=maxnumcompthreads(1);
> > C1=A*B;
> > maxnumcompthreads(2);
> > C2=A*B;
> > maxnumcompthreads(n);
> > isequal(C1,C2) % <- 1
> >
> > Bruno
>
> Bruno

Can you please try it with 5000x5000 matrices? Because with 1000x1000 matrices the two products are equal on my computer too. Try it with 5000x5000 matrices or bigger please. Thank you Victor.

Can you compare s with C1(500,500) and C2(500,500)

s=0;
for k=1:2000
  s=s+A(500,k)*B(k,500);
end;
s

% Bruno

> Can you please try it with 5000x5000 matrices? Because with 1000x1000 matrices the two products are equal on my computer too. Try it with 5000x5000 matrices or bigger please. Thank you Victor.

Work also fine with 5000

You might check if those has been changed: @double\mtimes, BLAS and MWLAPACK libraries.

Bruno

"Bruno Luong" <b.luong@fogale.findmycountry> wrote in message <h9icai$6vu$1@fred.mathworks.com>...
> Can you compare s with C1(500,500) and C2(500,500)
>
> s=0;
> for k=1:2000
> s=s+A(500,k)*B(k,500);
> end;
> s
>
> % Bruno

Yes the result ist numerically equal to the multithreaded product, both with one and with two cores.

What do you mean with cheking of \mtimes and the Blas? How do I do that? Thanks.

This is not a bug. To achieve highest performance, many computations will be
ordering the floating point arithmetics slighty different. All of these are
numerically corrent answer. Also it is the limitation of floating point
arithmetic.

Assume "+" and "-" to be very expensive that below is worth multhreading.

1e-16 + 1e-16 + 1e30 - 1e30

Forcing the computation to use 1 threads in double precision get

((1e-16 + 1e-16) + 1e30) - 1e30
= (2e-16 + 1e30) - 1e30
= 1e30 - 1e30
= 0

which gives you 0.

The most natural way to do the above using 2 threads are

(1e-16 + 1e-16) + (1e30 - 1e30)
= 2e-16 + 0
= 2e-16

In addition, by computing the matrix partially, you are forcing yet another
blocking of data and change the order of the floating point arithmetic. All
of these can lead to slightly different but correct numerical answers.

---Bob.


Consider changing the number of computational threads

"Bruno Luong" <b.luong@fogale.findmycountry> wrote in message
news:h9icla$aa$1@fred.mathworks.com...
>
>> Can you please try it with 5000x5000 matrices? Because with 1000x1000
>> matrices the two products are equal on my computer too. Try it with
>> 5000x5000 matrices or bigger please. Thank you Victor.
>
> Work also fine with 5000
>
> You might check if those has been changed: @double\mtimes, BLAS and
> MWLAPACK libraries.
>
> Bruno
>

"Bobby Cheng" <bcheng@mathworks.com> wrote in message <h9ijb2$7dp$1@fred.mathworks.com>...
> This is not a bug. To achieve highest performance, many computations will be
> ordering the floating point arithmetics slighty different. All of these are
> numerically corrent answer. Also it is the limitation of floating point
> arithmetic.
>
> Assume "+" and "-" to be very expensive that below is worth multhreading.
>
> 1e-16 + 1e-16 + 1e30 - 1e30
>
> Forcing the computation to use 1 threads in double precision get
>
> ((1e-16 + 1e-16) + 1e30) - 1e30
> = (2e-16 + 1e30) - 1e30
> = 1e30 - 1e30
> = 0
>
> which gives you 0.
>
> The most natural way to do the above using 2 threads are
>
> (1e-16 + 1e-16) + (1e30 - 1e30)
> = 2e-16 + 0
> = 2e-16
>
> In addition, by computing the matrix partially, you are forcing yet another
> blocking of data and change the order of the floating point arithmetic. All
> of these can lead to slightly different but correct numerical answers.
>

Wait a minute, Steve Lord informed us the "bug" (because it has been reported as such in Bug Reports archive) has been fixed in 2009B (see the post #16) in this thread:

http://www.mathworks.com/matlabcentral/newsreader/view_thread/260828

I have made my own test independently (without knowing the report) in 2009A and discover the inconsistent results when changing the number of CPU threads (for array larger than 88998, see my post #14), and the the result becomes consistent with 2009B (post #23), conforming to Steve's claim.

What is the real situation?

Bruno

"Victor kasaksha" <viphe@mail.ru> wrote in message <h9iedj$rnf$1@fred.mathworks.com>...
> "Bruno Luong" <b.luong@fogale.findmycountry> wrote in message <h9icai$6vu$1@fred.mathworks.com>...
> > Can you compare s with C1(500,500) and C2(500,500)
> >
> > s=0;
> > for k=1:2000
> > s=s+A(500,k)*B(k,500);
> > end;
> > s
> >
> > % Bruno
>
> Yes the result ist numerically equal to the multithreaded product, both with one and with two cores.
>
> What do you mean with cheking of \mtimes and the Blas? How do I do that? Thanks.

Under command line, type:

> which mtimes

It should be an builtin function.

The libraries BLAS and LAPACK are located in $MATLABROOT/bin/$PLATFORM, on Windows the file names are:

libmwblas.dll
libmwlapack.dll

Probably with extension *.so under Linux. Check if those files are not altered since installation.

What is the CPU of your computer?

Bruno

"Bruno Luong" <b.luong@fogale.findmycountry> wrote in message
news:h9ikon$cnt$1@fred.mathworks.com...
> "Bobby Cheng" <bcheng@mathworks.com> wrote in message
> <h9ijb2$7dp$1@fred.mathworks.com>...
>> This is not a bug. To achieve highest performance, many computations will
>> be
>> ordering the floating point arithmetics slighty different. All of these
>> are
>> numerically corrent answer. Also it is the limitation of floating point
>> arithmetic.
>>
>> Assume "+" and "-" to be very expensive that below is worth multhreading.
>>
>> 1e-16 + 1e-16 + 1e30 - 1e30
>>
>> Forcing the computation to use 1 threads in double precision get
>>
>> ((1e-16 + 1e-16) + 1e30) - 1e30
>> = (2e-16 + 1e30) - 1e30
>> = 1e30 - 1e30
>> = 0
>>
>> which gives you 0.
>>
>> The most natural way to do the above using 2 threads are
>>
>> (1e-16 + 1e-16) + (1e30 - 1e30)
>> = 2e-16 + 0
>> = 2e-16
>>
>> In addition, by computing the matrix partially, you are forcing yet
>> another
>> blocking of data and change the order of the floating point arithmetic.
>> All
>> of these can lead to slightly different but correct numerical answers.
>>
>
> Wait a minute, Steve Lord informed us the "bug" (because it has been
> reported as such in Bug Reports archive) has been fixed in 2009B (see the
> post #16) in this thread:
>
> http://www.mathworks.com/matlabcentral/newsreader/view_thread/260828
>
> I have made my own test independently (without knowing the report) in
> 2009A and discover the inconsistent results when changing the number of
> CPU threads (for array larger than 88998, see my post #14), and the the
> result becomes consistent with 2009B (post #23), conforming to Steve's
> claim.
>
> What is the real situation?

The bug to which I linked in that thread was specific to SUM and PROD (I
believe) and dealt with consecutive runs _using the same number of threads_.

This issue deals with MTIMES (although as per Bobby's example above, it
could occur with other functions) being run multiple times _using different
numbers of threads_.

--
Steve Lord
slord@mathworks.com
comp.soft-sys.matlab (CSSM) FAQ: http://matlabwiki.mathworks.com/MATLAB_FAQ

"Bruno Luong" <b.luong@fogale.findmycountry> wrote in message <h9il70$cge$1@fred.mathworks.com>...
> "Victor kasaksha" <viphe@mail.ru> wrote in message <h9iedj$rnf$1@fred.mathworks.com>...
> > "Bruno Luong" <b.luong@fogale.findmycountry> wrote in message <h9icai$6vu$1@fred.mathworks.com>...
> > > Can you compare s with C1(500,500) and C2(500,500)
> > >
> > > s=0;
> > > for k=1:2000
> > > s=s+A(500,k)*B(k,500);
> > > end;
> > > s
> > >
> > > % Bruno
> >
> > Yes the result ist numerically equal to the multithreaded product, both with one and with two cores.
> >
> > What do you mean with cheking of \mtimes and the Blas? How do I do that? Thanks.
>
> Under command line, type:
>
> > which mtimes
>
> It should be an builtin function.
>
> The libraries BLAS and LAPACK are located in $MATLABROOT/bin/$PLATFORM, on Windows the file names are:
>
> libmwblas.dll
> libmwlapack.dll
>
> Probably with extension *.so under Linux. Check if those files are not altered since installation.
>
> What is the CPU of your computer?
>
> Bruno

which mtimes
built-in (/usr/local/matlab09b/toolbox/matlab/ops/@double/mtimes) % double method

But with the dates of named files is something wrong. I ask my admin on monday about this. Thanks and a good weekend you all.

Victor

"Bobby Cheng" <bcheng@mathworks.com> wrote in message <h9ijb2$7dp$1@fred.mathworks.com>...
> This is not a bug. To achieve highest performance, many computations will be
> ordering the floating point arithmetics slighty different. All of these are
> numerically corrent answer. Also it is the limitation of floating point
> arithmetic.
>
> Assume "+" and "-" to be very expensive that below is worth multhreading.
>
> 1e-16 + 1e-16 + 1e30 - 1e30
>
> Forcing the computation to use 1 threads in double precision get
>
> ((1e-16 + 1e-16) + 1e30) - 1e30
> = (2e-16 + 1e30) - 1e30
> = 1e30 - 1e30
> = 0
>
> which gives you 0.
>
> The most natural way to do the above using 2 threads are
>
> (1e-16 + 1e-16) + (1e30 - 1e30)
> = 2e-16 + 0
> = 2e-16
>
> In addition, by computing the matrix partially, you are forcing yet another
> blocking of data and change the order of the floating point arithmetic. All
> of these can lead to slightly different but correct numerical answers.
>
> ---Bob.
>
>
> Consider changing the number of computational threads
>
> "Bruno Luong" <b.luong@fogale.findmycountry> wrote in message
> news:h9icla$aa$1@fred.mathworks.com...
> >
> >> Can you please try it with 5000x5000 matrices? Because with 1000x1000
> >> matrices the two products are equal on my computer too. Try it with
> >> 5000x5000 matrices or bigger please. Thank you Victor.
> >
> > Work also fine with 5000
> >
> > You might check if those has been changed: @double\mtimes, BLAS and
> > MWLAPACK libraries.
> >
> > Bruno
> >
>
@Bobby, its all true, but in my example there are no negative numbers and so the difference could not be grater than approximately (dim*eps). But I have here the third digits that are wrong. So it is no more numerically problems!

@Bruno, may be my Linux instalation is bad, but I get the same results on windows machine?

Hi Victor,

I can't reproduce your result. Can you send me and Steve Lord your matrix A
and B?

Just in case, by any chance you have use this

INTLAB INTerval LABoratory Version 5.5
07-May-2008 780 files, 690 m-files, 25,517 lines of Matlab

that toggles the rounding mode of MATLAB before you run the test? All bets
are off if the rounding mode is toggled.

---Bob.

"Rune Allnor" <allnor@tele.ntnu.no> wrote in message
news:3ed672cc-11cf-40da-81c4-51332ee4099f@p15g2000vbl.googlegroups.com...
On 25 Sep, 11:04, Rune Allnor <all...@tele.ntnu.no> wrote:
> On 25 Sep, 10:55, "Victor kasaksha" <vi...@mail.ru> wrote:
>
>
>
>
>
> > "Bruno Luong" <b.lu...@fogale.findmycountry> wrote in message
> > <h9hvfg$1...@fred.mathworks.com>...
>
> > > > >> C1(500,500)
> > > > ans =
> > > > 474.6958
> > > > >> C2(500,500)
> > > > ans =
> > > > 475.3501
>
> > > What value do you get for:
>
> > > A(500,:)*B(:,500)
>
> > > Bruno
>
> > O.K. again:
>
> > >> A = rand(2000);
>
> > B = rand(2000);
> > maxnumcompthreads(1);
> > C1 = A*B;
> > maxnumcompthreads(2);
> > C2 = A*B;
> > isequal(C1,C2)
> > C1(500,500)
> > C2(500,500)
> > ans =
> > 0
> > ans =
> > 509.2091
> > ans =
> > 507.8290>> A(500,:)*B(:,500)
>
> > ans =
> > 507.8290
>
> Seems to be a bug somewhere. I'd sen this example
> to mathworks tech support.

...which means "I would have sent this example to TMW
if I were you."

Just to avoid any misunderstanding: You should report
this example to TMW as a bug.

Rune

"Steven Lord" <slord@mathworks.com> wrote in message <h9ilv8$3uq$1@fred.mathworks.com>...

> The bug to which I linked in that thread was specific to SUM and PROD (I
> believe) and dealt with consecutive runs _using the same number of threads_.

Ah, refered to the rhread http://www.mathworks.com/matlabcentral/newsreader/view_thread/260828

Confusing might come from my part. In my post #14, I referred to the different results of SUM when using TWO differents maxnumcompthreads of input array larger than 88998 elements. This behavior happens with 2009A.

(Then you answer with the BUG report, and obviously concerning something else.)

I tried the same test with 2009B (two different maxnumcompthreads) and the results I get are identical (and identical to multi-thread in 2009A, and differ to all older MATLAB versions where only mono-threading is supported).

So I inferred (probably wrongly) that from 2009B, the monothread SUM and PROD is forced to perform the same calculation order as with MULTITHREAD.

So now to absolutely clear about this important issue. Here is the very straight forward questions for TMWr:

- Is that a warranty that PROD and SUM will give the same answer in 2009B for different number of threads? (it is not the case in 2009A).

- If not, can you provide an example where the results differ?

- Same questions with MTIMES.

It is absolutely important for me to understand those.

Many thanks,

Bruno

I agree that the third digit difference is puzzling

Can you tell us what MATLAB give you if you do

which mtimes(A,B)
which rand(2000)
A(1,1:3)
B(1:1:3)

My MATLAB session gives

>> which mtimes(A,B)
built-in
(M:\archive\R2009a\ship\win32\dist\toolbox\matlab\ops\@double\mtimes) %
double method
>> which rand(2000)
built-in (M:\archive\R2009a\ship\win32\dist\toolbox\matlab\randfun\rand)
>> A(1,1:3)
ans =
     0.066542 0.17146 0.28628
>> B(1:1:3)
ans =
      0.28707 0.30385 0.37076

---Bob.

"Victor kasaksha" <viphe@mail.ru> wrote in message
news:h9in8n$198$1@fred.mathworks.com...
> "Bobby Cheng" <bcheng@mathworks.com> wrote in message
> <h9ijb2$7dp$1@fred.mathworks.com>...
>> This is not a bug. To achieve highest performance, many computations will
>> be
>> ordering the floating point arithmetics slighty different. All of these
>> are
>> numerically corrent answer. Also it is the limitation of floating point
>> arithmetic.
>>
>> Assume "+" and "-" to be very expensive that below is worth multhreading.
>>
>> 1e-16 + 1e-16 + 1e30 - 1e30
>>
>> Forcing the computation to use 1 threads in double precision get
>>
>> ((1e-16 + 1e-16) + 1e30) - 1e30
>> = (2e-16 + 1e30) - 1e30
>> = 1e30 - 1e30
>> = 0
>>
>> which gives you 0.
>>
>> The most natural way to do the above using 2 threads are
>>
>> (1e-16 + 1e-16) + (1e30 - 1e30)
>> = 2e-16 + 0
>> = 2e-16
>>
>> In addition, by computing the matrix partially, you are forcing yet
>> another
>> blocking of data and change the order of the floating point arithmetic.
>> All
>> of these can lead to slightly different but correct numerical answers.
>>
>> ---Bob.
>>
>>
>> Consider changing the number of computational threads
>>
>> "Bruno Luong" <b.luong@fogale.findmycountry> wrote in message
>> news:h9icla$aa$1@fred.mathworks.com...
>> >
>> >> Can you please try it with 5000x5000 matrices? Because with 1000x1000
>> >> matrices the two products are equal on my computer too. Try it with
>> >> 5000x5000 matrices or bigger please. Thank you Victor.
>> >
>> > Work also fine with 5000
>> >
>> > You might check if those has been changed: @double\mtimes, BLAS and
>> > MWLAPACK libraries.
>> >
>> > Bruno
>> >
>>
> @Bobby, its all true, but in my example there are no negative numbers and
> so the difference could not be grater than approximately (dim*eps). But I
> have here the third digits that are wrong. So it is no more numerically
> problems!
>
> @Bruno, may be my Linux instalation is bad, but I get the same results on
> windows machine?
>

Dear Bob, again:

-------------------------------------------------------------------------------------
MATLAB Version 7.9.0.529 (R2009b)
MATLAB License Number: 46423
Operating System: Linux 2.6.27.29-0.1-pae #1 SMP 2009-08-15 17:53:59 +0200 i686
Java VM Version: Java 1.6.0_12-b04 with Sun Microsystems Inc. Java HotSpot(TM) Client VM mixed mode
-------------------------------------------------------------------------------------

built-in (/usr/local/matlab09b/toolbox/matlab/ops/@single/times) % single method

>> which times(A,B) %A,B from above
built-in (/usr/local/matlab09b/toolbox/matlab/ops/@double/times) % double method

>> which rand
built-in (/usr/local/matlab09b/toolbox/matlab/randfun/rand)

Thanks, and a good weekend, I go home now. By
 

Hi Victor,

I would be very help if you can send me and Steve Lord matrices A and B.
Steve and I both cannot reproduce the issue in house.

---Bob.

"Victor kasaksha" <viphe@mail.ru> wrote in message
news:h9is4a$r9p$1@fred.mathworks.com...
> Dear Bob, again:
>
> -------------------------------------------------------------------------------------
> MATLAB Version 7.9.0.529 (R2009b)
> MATLAB License Number: 46423
> Operating System: Linux 2.6.27.29-0.1-pae #1 SMP 2009-08-15 17:53:59 +0200
> i686
> Java VM Version: Java 1.6.0_12-b04 with Sun Microsystems Inc. Java
> HotSpot(TM) Client VM mixed mode
> -------------------------------------------------------------------------------------
>
> built-in (/usr/local/matlab09b/toolbox/matlab/ops/@single/times) % single
> method
>
>>> which times(A,B) %A,B from above
> built-in (/usr/local/matlab09b/toolbox/matlab/ops/@double/times) % double
> method
>
>>> which rand
> built-in (/usr/local/matlab09b/toolbox/matlab/randfun/rand)
>
> Thanks, and a good weekend, I go home now. By
>
>

On Sep 25, 4:42 am, "Bruno Luong" <b.lu...@fogale.findmycountry>
wrote:
> Work also fine on XP 32 Intel Core 2 Duo. So I don't know what's up with your computer.
>
> > Work fine for me (2009B, Vista 64):
>
> > A=rand(2000,2000);
> > B=rand(2000,2000);
> > n=maxnumcompthreads(1);
> > C1=A*B;
> > maxnumcompthreads(2);
> > C2=A*B;
> > maxnumcompthreads(n);
> > isequal(C1,C2) % <- 1
>
> > Bruno
>
> Bruno

Just a comment:
For my XP 32 Intel Core 2 Duo setup running 2009b
with VER returning
-------------------------------------------------------------------------------------
MATLAB Version 7.9.0.529 (R2009b)
MATLAB License Number: 534484
Operating System: Microsoft Windows XP Version 5.1 (Build 2600:
Service Pack 2)
Java VM Version: Java 1.6.0_12-b04 with Sun Microsystems Inc. Java
HotSpot(TM) Client VM mixed mode
-------------------------------------------------------------------------------------
MATLAB Version
7.9 (R2009b)
Image Processing Toolbox Version
6.4 (R2009b)
Spline Toolbox Version
3.3.7 (R2009b)


I seem to be getting the same thing as the OP.
A=rand(2000,2000);
B=rand(2000,2000);
n=maxnumcompthreads(1);
C1=A*B;
maxnumcompthreads(2);
C2=A*B;
maxnumcompthreads(n);
isequal(C1,C2) % <- 0

But, like he said, doing rand(1000,1000) for each returns 1.
-Nathan

Nathan,

As I explained earlier, C1 and C2 being identitical is not important here.

Standard roundoff error analysis shows that we expect 10^-12 difference.
Both solutions are numerically correct.

However, the troubling fact is that, on Victor machine, The error is of
order 1. It is 10^12 times better than expected. This is what we should get
to the bottom of.

Having said that, you are basically like me being not able to reproduce what
Victor is seeing.

---Bob.

"Nathan" <ngreco32@gmail.com> wrote in message
news:0a4afd9f-a8ca-466c-a6e7-abc192545773@m33g2000pri.googlegroups.com...
On Sep 25, 4:42 am, "Bruno Luong" <b.lu...@fogale.findmycountry>
wrote:
> Work also fine on XP 32 Intel Core 2 Duo. So I don't know what's up with
> your computer.
>
> > Work fine for me (2009B, Vista 64):
>
> > A=rand(2000,2000);
> > B=rand(2000,2000);
> > n=maxnumcompthreads(1);
> > C1=A*B;
> > maxnumcompthreads(2);
> > C2=A*B;
> > maxnumcompthreads(n);
> > isequal(C1,C2) % <- 1
>
> > Bruno
>
> Bruno

Just a comment:
For my XP 32 Intel Core 2 Duo setup running 2009b
with VER returning
-------------------------------------------------------------------------------------
MATLAB Version 7.9.0.529 (R2009b)
MATLAB License Number: 534484
Operating System: Microsoft Windows XP Version 5.1 (Build 2600:
Service Pack 2)
Java VM Version: Java 1.6.0_12-b04 with Sun Microsystems Inc. Java
HotSpot(TM) Client VM mixed mode
-------------------------------------------------------------------------------------
MATLAB Version
7.9 (R2009b)
Image Processing Toolbox Version
6.4 (R2009b)
Spline Toolbox Version
3.3.7 (R2009b)


I seem to be getting the same thing as the OP.
A=rand(2000,2000);
B=rand(2000,2000);
n=maxnumcompthreads(1);
C1=A*B;
maxnumcompthreads(2);
C2=A*B;
maxnumcompthreads(n);
isequal(C1,C2) % <- 0

But, like he said, doing rand(1000,1000) for each returns 1.
-Nathan

I agree that it is important to clear the issues on hand. Here is my attempt
to address issue.

There is a bug in MATLAB as referred to
http://www.mathworks.com/support/bugreports/532399, in when two consecutive
executions of the same built-in function with the same data yielded
different results in the same MATLAB session.

The key phrases here are "consecutive executions" and "same MATLAB session".
Say foo is a built-in function, then

isequalwithequalnans(foo(b),foo(b)) %should return true.

Exceptions are RAND and related functions that the results depends on
previous computations.

As to your questions, let ignore NaN and Inf for now, as they make the
definitions of equal somewhat different. Assume matrix(A) to be finite.

sum(A(:)) == sum(A(:)) % should be true, otherwise is a bug
maxNumCompThreads(1);
sum(A(:)) == sum(A(:)) % should be true, otherwise is a bug
maxNumCompThreads(2)
sum(A(:)) == sum(A(:)) % should be true, otherwise is a bug

For above to be true, it poses a requirement on the threading strategy that
sum can use. It basically says if you give me the same threading
environment, MATLAB will always threads the computation the same way, as
least from the customer points of view. As to your example,

maxNumCompThreads(1);
a1 = sum(A(:))
maxNumCompThreads(2);
b1 = sum(A(:))
maxNumCompThreads(1);
a2 = sum(A(:))
maxNumCompThreads(2);
b2 = sum(A(:))
isequal(a1,b1) % may not be true, but it is not a bug
isequal(a2,b2) % may not be true, but it is not a bug
isequal(a1,a2) % should be true, otherwise is a bug
isequal(b1,b2) % should be true, otherwise is a bug

So what else can cause a1 and b1 to be potentially different?
(1) Change rounding mode in between.
(2) Change computer in between
(3) Change version of MATLAB in between
(4) Change threading levels in between
(5) Change OS in between
(6) Change processor in between
....

I hope this helps clear the picture. If not, let me know
---Bob.

"Bruno Luong" <b.luong@fogale.findmycountry> wrote in message
news:h9io14$mjs$1@fred.mathworks.com...
> "Steven Lord" <slord@mathworks.com> wrote in message
> <h9ilv8$3uq$1@fred.mathworks.com>...
>
>> The bug to which I linked in that thread was specific to SUM and PROD (I
>> believe) and dealt with consecutive runs _using the same number of
>> threads_.
>
> Ah, refered to the rhread
> http://www.mathworks.com/matlabcentral/newsreader/view_thread/260828
>
> Confusing might come from my part. In my post #14, I referred to the
> different results of SUM when using TWO differents maxnumcompthreads of
> input array larger than 88998 elements. This behavior happens with 2009A.
>
> (Then you answer with the BUG report, and obviously concerning something
> else.)
>
> I tried the same test with 2009B (two different maxnumcompthreads) and the
> results I get are identical (and identical to multi-thread in 2009A, and
> differ to all older MATLAB versions where only mono-threading is
> supported).
>
> So I inferred (probably wrongly) that from 2009B, the monothread SUM and
> PROD is forced to perform the same calculation order as with MULTITHREAD.
>
> So now to absolutely clear about this important issue. Here is the very
> straight forward questions for TMWr:
>
> - Is that a warranty that PROD and SUM will give the same answer in 2009B
> for different number of threads? (it is not the case in 2009A).
>
> - If not, can you provide an example where the results differ?
>
> - Same questions with MTIMES.
>
> It is absolutely important for me to understand those.
>
> Many thanks,
>
> Bruno
>

Thank you Bobby.

Bruno

Nathan <ngreco32@gmail.com> wrote in message <0a4afd9f-a8ca-466c-a6e7-abc192545773@m33g2000pri.googlegroups.com>...

> I seem to be getting the same thing as the OP.
> A=rand(2000,2000);
> B=rand(2000,2000);
> n=maxnumcompthreads(1);
> C1=A*B;
> maxnumcompthreads(2);
> C2=A*B;
> maxnumcompthreads(n);
> isequal(C1,C2) % <- 0
>
> But, like he said, doing rand(1000,1000) for each returns 1.
> -Nathan

I have run 1000 random cases like above (both 2009A & 2009B + Vista), without a single time where the results C1 & C2 differ.

IMO there is still BUG in Matlab multi threading codes. It manifest in various degrees: strong for Victor, weaker with you Nathan, never (yet) with me.

Also during it is runing, if I close Matlab command window, it crashes and I get a bunch of error messages.

Good luck to all,

Bruno

% Script to check mono/multithreading maxtrix product

clear
k = 0;
while 1
    A=rand(2000);
    B=rand(2000);
    
    maxNumCompThreads(1);
    tic; C1=A*B; toc
    
    maxNumCompThreads(2);
    tic; C2=A*B; toc
    
    if ~isequal(C1,C2)
        disp('Differ') % <- never go there
        save MTimesDebug.mat A B C1 C2
        break
    end
    
    k = k+1
    
end

% Bruno

"Bobby Cheng" <bcheng@mathworks.com> wrote in message <h9kavf$77g$1@fred.mathworks.com>...

> (1) Change rounding mode in between.
>...

Do you refer to the Intel floating point control word it can be set by _controlfp? Is there any mechanism in Matlab to shield against changes by non matlab thread? What are the recommendation can you give when a compiled shared library Matlab is used together with other libraries?

Bruno

Yes, something like that.

I believe that MATLAB does a pretty good job in protecting itself against
other applications in resetting the states. So customers should not need to
worry about it. If you discover a problem, please contact our support.

Having said that, I think it is always possible to break it on purpose,
similar to writing a mex file that seg-v and crashes MATLAB, but I have not
tried and would urge everyone not to try too hard. :)

---Bob.

"Bruno Luong" <b.luong@fogale.findmycountry> wrote in message
news:h9l7qp$smd$1@fred.mathworks.com...
> "Bobby Cheng" <bcheng@mathworks.com> wrote in message
> <h9kavf$77g$1@fred.mathworks.com>...
>
>> (1) Change rounding mode in between.
>>...
>
> Do you refer to the Intel floating point control word it can be set by
> _controlfp? Is there any mechanism in Matlab to shield against changes by
> non matlab thread? What are the recommendation can you give when a
> compiled shared library Matlab is used together with other libraries?
>
> Bruno
>

"Bobby Cheng" <bcheng@mathworks.com> wrote in message <h9n3fm$3t2$1@fred.mathworks.com>...
> Yes, something like that.
>
> I believe that MATLAB does a pretty good job in protecting itself against
> other applications in resetting the states. So customers should not need to
> worry about it. If you discover a problem, please contact our support.
>
> Having said that, I think it is always possible to break it on purpose,
> similar to writing a mex file that seg-v and crashes MATLAB, but I have not
> tried and would urge everyone not to try too hard. :)
>

I have not seen the round-off mode being altered, however we have seen reproducible crashes of Matlab compiled shared library when working with some third party DLL. I traced back as I have a strong suspicious the root cause is that the floating point exception handler (controlled by the same controll word) is modified by the third party DLL. This is really a pain.

Bruno

Victor Nathan and all those who get different matrix results with different thread setup, could you try the following script and post what you get. Thanks.

% Test if different results of MTIMES are due to
% arithmtic order (likely) of thread or bug

n = 2000; % matrix size
A = eps(1)+zeros(n);
A(:,1) = 2;
B = ones(n);

warnstate=warning('off','all');
n = maxNumCompThreads('automatic');

maxNumCompThreads(1);
C1=A*B;

maxNumCompThreads(2);
C2=A*B;

d = (C1-C2)./eps(1);
md = max(abs(d(:)));
fprintf('md= %d/%d\n', md, size(A,2)-1);

maxerror = (size(A,2)-1)*eps(1);
if any(C1(:)>2+maxerror) || any(C1(:)<2) || ...
   any(C1(:)>2+maxerror) || any(C1(:)<2)
    disp('BUG in MTIMES');
else
    disp('OK');
end

maxNumCompThreads(n);
warning(warnstate);

% Bruno

MATLAB, in my knowledge, does not try catching floating point exception.

If a shared library is written to catch floating point exception, then there
is very little MATLAB can do about it. :(

---Bob.


"Bruno Luong" <b.luong@fogale.findmycountry> wrote in message
news:h9n528$ea1$1@fred.mathworks.com...
> "Bobby Cheng" <bcheng@mathworks.com> wrote in message
> <h9n3fm$3t2$1@fred.mathworks.com>...
>> Yes, something like that.
>>
>> I believe that MATLAB does a pretty good job in protecting itself against
>> other applications in resetting the states. So customers should not need
>> to
>> worry about it. If you discover a problem, please contact our support.
>>
>> Having said that, I think it is always possible to break it on purpose,
>> similar to writing a mex file that seg-v and crashes MATLAB, but I have
>> not
>> tried and would urge everyone not to try too hard. :)
>>
>
> I have not seen the round-off mode being altered, however we have seen
> reproducible crashes of Matlab compiled shared library when working with
> some third party DLL. I traced back as I have a strong suspicious the root
> cause is that the floating point exception handler (controlled by the same
> controll word) is modified by the third party DLL. This is really a pain.
>
> Bruno
>

Victor,

I am looking for mtimes not times, can you run the exact command in MATLAB
and tell us what you see?

which mtimes(A,B)
which rand(2000)

---Bob.

"Bobby Cheng" <bcheng@mathworks.com> wrote in message
news:h9j0dl$enm$1@fred.mathworks.com...
> Hi Victor,
>
> I would be very help if you can send me and Steve Lord matrices A and B.
> Steve and I both cannot reproduce the issue in house.
>
> ---Bob.
>
> "Victor kasaksha" <viphe@mail.ru> wrote in message
> news:h9is4a$r9p$1@fred.mathworks.com...
>> Dear Bob, again:
>>
>> -------------------------------------------------------------------------------------
>> MATLAB Version 7.9.0.529 (R2009b)
>> MATLAB License Number: 46423
>> Operating System: Linux 2.6.27.29-0.1-pae #1 SMP 2009-08-15 17:53:59
>> +0200 i686
>> Java VM Version: Java 1.6.0_12-b04 with Sun Microsystems Inc. Java
>> HotSpot(TM) Client VM mixed mode
>> -------------------------------------------------------------------------------------
>>
>> built-in (/usr/local/matlab09b/toolbox/matlab/ops/@single/times) %
>> single method
>>
>>>> which times(A,B) %A,B from above
>> built-in (/usr/local/matlab09b/toolbox/matlab/ops/@double/times) %
>> double method
>>
>>>> which rand
>> built-in (/usr/local/matlab09b/toolbox/matlab/randfun/rand)
>>
>> Thanks, and a good weekend, I go home now. By
>>
>>
>
>
>

Hello all, I apologize for the late answer:

first:
----------------------------------------------------------------------------------------
which mtimes
built-in (/usr/local/matlab09b/toolbox/matlab/ops/@double/mtimes) % double method

which rand
built-in (/usr/local/matlab09b/toolbox/matlab/randfun/rand)
-----------------------------------------------------------------------------------------

second:
-----------------------------------------------------------------------------------------
consider/execute following code:

n = 2000;

a = 1e8; b = 2e8;

A = a + (b - a).*rand(n,'single');
B = a + (b - a).*rand(n,'single');
A = mod(A,10);
B = mod(B,10);

maxnumcompthreads(1);
Cs1 = A*B;
Cd1 = double(A)*double(B);

maxnumcompthreads(2);
Cs2 = A*B;
Cd2 = double(A)*double(B);

Aint = uint32(A);
Bint = uint32(B);
Cint = uint32(zeros(n));
i = 1;
for j = 1:n
    for k = 1:n
        Cint(i,j) = Cint(i,j) + Aint(i,k)*Bint(k,j);
    end
end

isequal(Cs1,Cs2)
isequal(Cd1,Cd2)

Cd1(1,100)
Cd2(1,100)
Cint(1,100)

ans =
     1 %-> single is O.K.
ans =
     0 %-> double is not O.K.
ans =
       32288 % one thread is wrong
ans =
       31504 % 2 threads and
ans =
       31504 % my own integer computation are equal,
                   % so I think single thread product is wrong

---------------------------------------------------------------------------
third: code from above produces:

md= 0/1999
OK

"Bruno Luong" <b.luong@fogale.findmycountry> wrote in message
news:h9n528$ea1$1@fred.mathworks.com...
> "Bobby Cheng" <bcheng@mathworks.com> wrote in message
> <h9n3fm$3t2$1@fred.mathworks.com>...
>> Yes, something like that.
>>
>> I believe that MATLAB does a pretty good job in protecting itself against
>> other applications in resetting the states. So customers should not need
>> to
>> worry about it. If you discover a problem, please contact our support.
>>
>> Having said that, I think it is always possible to break it on purpose,
>> similar to writing a mex file that seg-v and crashes MATLAB, but I have
>> not
>> tried and would urge everyone not to try too hard. :)
>>
>
> I have not seen the round-off mode being altered, however we have seen
> reproducible crashes of Matlab compiled shared library when working with
> some third party DLL. I traced back as I have a strong suspicious the root
> cause is that the floating point exception handler (controlled by the same
> controll word) is modified by the third party DLL. This is really a pain.

Have you sent the code you're using with which you can reproduce the crash
(along with the crash dump file, if any) to Technical Support for
investigation? If not, please do so if possible.

--
Steve Lord
slord@mathworks.com
comp.soft-sys.matlab (CSSM) FAQ: http://matlabwiki.mathworks.com/MATLAB_FAQ

It seems to be complicated to report a bug on mathworks, so I dont want to do that. I searches for 10 minites where can I do that, but nothing found. If they are interested in that, so they can found all here:



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

-------------------------------------------------------------------------------------
MATLAB Version 7.9.0.529 (R2009b)
MATLAB License Number: 46423
Operating System: Linux 2.6.27.29-0.1-pae #1 SMP 2009-08-15 17:53:59 +0200 i686
Java VM Version: Java 1.6.0_12-b04 with Sun Microsystems Inc. Java HotSpot(TM) Client VM mixed mode
-------------------------------------------------------------------------------------
MATLAB Version 7.9 (R2009b)
Simulink Version 7.4 (R2009b)
Bioinformatics Toolbox Version 3.4 (R2009b)
Communications Blockset Version 4.3 (R2009b)
Communications Toolbox Version 4.4 (R2009b)
Control System Toolbox Version 8.4 (R2009b)
Conversion to SeDuMi Version routines for reading in problems from SDPPack,
Curve Fitting Toolbox Version 2.1 (R2009b)
Fixed-Point Toolbox Version 3.0 (R2009b)
Fuzzy Logic Toolbox Version 2.2.10 (R2009b)
Genetic Algorithm and Direct Search Toolbox Version 2.4.2 (R2009b)
INTLAB INTerval LABoratory Version 5.5 07-May-2008 780 files, 690 m-files, 25,517 lines of Matlab
Image Processing Toolbox Version 6.4 (R2009b)
Instrument Control Toolbox Version 2.9 (R2009b)
MATLAB Builder JA Version 2.0.4 (R2009b)
MATLAB Compiler Version 4.11 (R2009b)
Mapping Toolbox Version 3.0 (R2009b)
Model Predictive Control Toolbox Version 3.1.1 (R2009b)
Neural Network Toolbox Version 6.0.3 (R2009b)
Optimization Toolbox Version 4.3 (R2009b)
Parallel Computing Toolbox Version 4.2 (R2009b)
Partial Differential Equation Toolbox Version 1.0.15 (R2009b)
RF Blockset Version 2.5 (R2009b)
RF Toolbox Version 2.6 (R2009b)
Real-Time Workshop Version 7.4 (R2009b)
Real-Time Workshop Embedded Coder Version 5.4 (R2009b)
Regularization Tools Version 4.0
Robust Control Toolbox Version 3.4 (R2009b)
Signal Processing Blockset Version 6.10 (R2009b)
Signal Processing Toolbox Version 6.12 (R2009b)
SimElectronics Version 1.3 (R2009b)
SimMechanics Version 3.1.1 (R2009b)
SimPowerSystems Version 5.2 (R2009b)
Simscape Version 3.2 (R2009b)
Simulink Control Design Version 3.0 (R2009b)
Simulink Design Optimization Version 1.1 (R2009b)
Simulink Fixed Point Version 6.2 (R2009b)
Spline Toolbox Version 3.3.7 (R2009b)
Stateflow Version 7.4 (R2009b)
Stateflow Coder Version 7.4 (R2009b)
Statistics Toolbox Version 7.2 (R2009b)
System Identification Toolbox Version 7.3.1 (R2009b)
Video and Image Processing Blockset Version 2.8 (R2009b)
Wavelet Toolbox

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Code:



n = 2000;

a = 1e8; b = 2e8;

A = a + (b - a).*rand(n,'single');
B = a + (b - a).*rand(n,'single');
A = mod(A,10);
B = mod(B,10);

maxnumcompthreads(1);
Cs1 = A*B;
Cd1 = double(A)*double(B);

maxnumcompthreads(2);
Cs2 = A*B;
Cd2 = double(A)*double(B);

if ~isequal(Cs1,Cs2)
    disp('error in single mtimes');
    Cs1(1,100)
    Cs2(1,100)
end

if ~isequal(Cd1,Cd2)
    disp('error in double mtimes');
    Cd1(1,100)
    Cd2(1,100)
end

O.K. I did that. Thanks.

"Steven Lord" <slord@mathworks.com> wrote in message <h9qh7t$t7o$1@fred.mathworks.com>...

>
> Have you sent the code you're using with which you can reproduce the crash
> (along with the crash dump file, if any) to Technical Support for
> investigation? If not, please do so if possible.
>

1. There is no crash dump. The soft just crash.

2. As it involves also a third party library (we don't have the source code) I have my doubt that Mathworks can effectively help us.

Thanks anyway,

Bruno

"Bruno Luong" <b.luong@fogale.findmycountry> wrote in message
news:h9qkei$fl$1@fred.mathworks.com...
> "Steven Lord" <slord@mathworks.com> wrote in message
> <h9qh7t$t7o$1@fred.mathworks.com>...
>
>>
>> Have you sent the code you're using with which you can reproduce the
>> crash
>> (along with the crash dump file, if any) to Technical Support for
>> investigation? If not, please do so if possible.
>>
>
> 1. There is no crash dump. The soft just crash.
>
> 2. As it involves also a third party library (we don't have the source
> code) I have my doubt that Mathworks can effectively help us.

Depending on what the third-party library is and who created it, we may be
able to obtain a copy from the authors and/or work with them to diagnose the
cause of the crash.

--
Steve Lord
slord@mathworks.com
comp.soft-sys.matlab (CSSM) FAQ: http://matlabwiki.mathworks.com/MATLAB_FAQ

"Victor kasaksha" <viphe@mail.ru> wrote in message
news:h9qikd$u9$1@fred.mathworks.com...
> It seems to be complicated to report a bug on mathworks, so I dont want to
> do that. I searches for 10 minites where can I do that, but nothing found.
> If they are interested in that, so they can found all here:

Use the "Request Technical Support" or "Request an Enhancement, or Report a
Bug or Documentation Issue" links on the "Contact Us" page linked from the
top of pages on mathworks.com:

http://www.mathworks.com/company/aboutus/contact_us/

> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>
> -------------------------------------------------------------------------------------
> MATLAB Version 7.9.0.529 (R2009b)

*snip*

> INTLAB INTerval LABoratory Version 5.5
> 07-May-2008 780 files, 690 m-files, 25,517 lines of Matlab

As Bobby requested earlier, do you use INTLAB before running the code that
reproduces this problem? On the INTLAB webpage, it says:

" INTLAB routines do not make an assumption on the current rounding mode but
always set it to the correct value, so this does not cause problems with
INTLAB routines. "

and if you need to use INTLAB before reproducing this behavior, I suspect
that it's modifications to the rounding mode affect the threading behavior
in the BLAS.

Try starting up a completely fresh session of MATLAB. DON'T use INTLAB
before running the code below (if it runs some routines at startup, comment
them out in your startup.m file.) Then try reproducing this behavior.

*snip*

> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> Code:

I've tried running this but was not able to reproduce this problem.

*snip*

--
Steve Lord
slord@mathworks.com
comp.soft-sys.matlab (CSSM) FAQ: http://matlabwiki.mathworks.com/MATLAB_FAQ

"Victor kasaksha" <viphe@mail.ru> wrote in message <h9htf1$rrd$1@fred.mathworks.com>...
> O.K. now a windows Sysem:
>
> -------------------------------------------------------------------------------------
> MATLAB Version 7.9.0.529 (R2009b)
> MATLAB License Number: 46423
> Operating System: Microsoft Windows Vista Version 6.1 (Build 7600)
> Java VM Version: Java 1.6.0_12-b04 with Sun Microsystems Inc. Java HotSpot(TM) Client VM mixed mode
> -------------------------------------------------------------------------------------
>
>
> A = rand(2000);
> B = rand(2000);
> maxnumcompthreads(1)
> C1 = A*B;
> maxnumcompthreads(2)
> C2 = A*B;
> isequal(C1,C2)
>
> ans =
> 0
>
> and more:
>
> >> C1(500,500)
> ans =
> 474.6958
> >> C2(500,500)
> ans =
> 475.3501
>
> and this is evil !!!

I can reproduce this also
XP Sp2 2 Core duo

>> C1(50,50)

ans =

  492.3313

>> C2(50,50)

ans =

  493.1254

>
> I can reproduce this also
> XP Sp2 2 Core duo
>
> >> C1(50,50)
>
> ans =
>
> 492.3313
>
> >> C2(50,50)
>
> ans =
>
> 493.1254

Any error significantly larger than eps(1)*2000 (=4.4409e-013) is VERY suspicious. It seems like a Bug indeed.

The question is: why I'm one of the lucky persons (hello anyone else out there?) who is not affected.

Bruno

Budias,

Thank you for helping us tracking this down. It does seem like a bug.

Can you confirm that you have 2 Core Duo processors in your machine?

It would be helpful if you can show us what

My Computer --> Properties -->General

tells you about the processor/system.

I have one Core Duo in my laptop and cannot reproduce the problem.
I cannot reproduce my problem on a Core 2 Duo machine either.

MATLAB uses Intel MKL which is optimized for individual processors. It is
not unusual that a bug show up only in a subset of processors.

---Bob.

"Bruno Luong" <b.luong@fogale.findmycountry> wrote in message
news:h9r54u$m5o$1@fred.mathworks.com...
>
>>
>> I can reproduce this also
>> XP Sp2 2 Core duo
>>
>> >> C1(50,50)
>>
>> ans =
>>
>> 492.3313
>>
>> >> C2(50,50)
>>
>> ans =
>>
>> 493.1254
>
> Any error significantly larger than eps(1)*2000 (=4.4409e-013) is VERY
> suspicious. It seems like a Bug indeed.
>
> The question is: why I'm one of the lucky persons (hello anyone else out
> there?) who is not affected.
>
> Bruno
>

Victor,

It would be helpful if you can show us what

cat /proc/cpuinfo

tells you about your processors.

It does seem like a bug. But until we have a way to reproduce it, it is hard
to nail it down.

Thanks,
---Bob.

"Victor kasaksha" <viphe@mail.ru> wrote in message
news:h9q9m3$fe5$1@fred.mathworks.com...
> Hello all, I apologize for the late answer:
>
> first:
> ----------------------------------------------------------------------------------------
> which mtimes
> built-in (/usr/local/matlab09b/toolbox/matlab/ops/@double/mtimes) %
> double method
>
> which rand
> built-in (/usr/local/matlab09b/toolbox/matlab/randfun/rand)
> -----------------------------------------------------------------------------------------
>
> second:
> -----------------------------------------------------------------------------------------
> consider/execute following code:
>
> n = 2000;
>
> a = 1e8; b = 2e8;
>
> A = a + (b - a).*rand(n,'single');
> B = a + (b - a).*rand(n,'single');
> A = mod(A,10);
> B = mod(B,10);
>
> maxnumcompthreads(1);
> Cs1 = A*B;
> Cd1 = double(A)*double(B);
>
> maxnumcompthreads(2);
> Cs2 = A*B;
> Cd2 = double(A)*double(B);
>
> Aint = uint32(A);
> Bint = uint32(B);
> Cint = uint32(zeros(n));
> i = 1;
> for j = 1:n
> for k = 1:n
> Cint(i,j) = Cint(i,j) + Aint(i,k)*Bint(k,j);
> end
> end
>
> isequal(Cs1,Cs2)
> isequal(Cd1,Cd2)
>
> Cd1(1,100)
> Cd2(1,100)
> Cint(1,100)
>
> ans =
> 1 %-> single is O.K.
> ans =
> 0 %-> double is not O.K.
> ans =
> 32288 % one thread is wrong
> ans =
> 31504 % 2 threads and
> ans =
> 31504 % my own integer computation are equal,
> % so I think single thread product is wrong
>
> ---------------------------------------------------------------------------
> third: code from above produces:
>
> md= 0/1999
> OK
>

Hello all,

I'm happy that now a second person have the same bug/problem. Here you can see what my cpu-version is:

cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz
stepping : 10
cpu MHz : 1998.000
cache size : 6144 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts pni monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm
bogomips : 5999.27
clflush size : 64
power management:

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz
stepping : 10
cpu MHz : 1998.000
cache size : 6144 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 1
initial apicid : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts pni monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm
bogomips : 5999.66
clflush size : 64
power management:

On our "workstation" (2 Xeons) the problem does not arise. It seems indeed to be a hardware related problem.

I will try to reproduce the issue without INTLAB, but I think it is independent from the INTLAB.

My Dell (Intel(R) Core(TM)2 Duo CPU E8500 @ 3.16GHz) does not seem to be affected by the bug.

Bruno

"Bruno Luong" <b.luong@fogale.findmycountry> wrote in message <h9saub$pik$1@fred.mathworks.com>...
> My Dell (Intel(R) Core(TM)2 Duo CPU E8500 @ 3.16GHz) does not seem to be affected by the bug.
>
Another test from me:
MATLAB Version 7.8.0.347 (R2009a)
Operating System: Microsoft Windows XP Version 5.1 (Build 2600: Service Pack 3)
Java VM Version: Java 1.6.0_04-b12 with Sun Microsystems Inc. Java HotSpot(TM) Client VM mixed mode

Core 2 Duo, E8400 3GHz

Works fine.

"Bobby Cheng" <bcheng@mathworks.com> wrote in message <h9s1m7$8uc$1@fred.mathworks.com>...
> Budias,
>
> Thank you for helping us tracking this down. It does seem like a bug.
>
> Can you confirm that you have 2 Core Duo processors in your machine?
>
> It would be helpful if you can show us what
>
> My Computer --> Properties -->General
>
> tells you about the processor/system.

Hi,

My system is

Intel Core 2 Duo, T 9300 @2.50GHz, 797 MHz, 1.98 GB of RAM

Any updates on this subject so far?


"Bruno Luong" <b.luong@fogale.findmycountry> wrote in message <h9r54u$m5o$1@fred.mathworks.com>...
>
> >
> > I can reproduce this also
> > XP Sp2 2 Core duo
> >
> > >> C1(50,50)
> >
> > ans =
> >
> > 492.3313
> >
> > >> C2(50,50)
> >
> > ans =
> >
> > 493.1254
>
> Any error significantly larger than eps(1)*2000 (=4.4409e-013) is VERY suspicious. It seems like a Bug indeed.
>
> The question is: why I'm one of the lucky persons (hello anyone else out there?) who is not affected.
>
> Bruno

I can give my example where the problem occurs when passing from 1000x1000 to 2000x2000:

Code:
Nel=500;
A=rand(Nel,Nel);
B=rand(Nel,Nel);
n=maxnumcompthreads(1);
C1=A*B;
maxnumcompthreads(2);
C2=A*B;
maxnumcompthreads(n);
isequal(C1,C2)

%Result: isequal(C1,C2) -> 1

%--------------

Nel=1000;
A=rand(Nel,Nel);
B=rand(Nel,Nel);
n=maxnumcompthreads(1);
C1=A*B;
maxnumcompthreads(2);
C2=A*B;
maxnumcompthreads(n);
isequal(C1,C2)

%Result: isequal(C1,C2) -> 1

%------------------

Nel=2000;
A=rand(Nel,Nel);
B=rand(Nel,Nel);
n=maxnumcompthreads(1);
C1=A*B;
maxnumcompthreads(2);
C2=A*B;
maxnumcompthreads(n);
isequal(C1,C2)

%Result: isequal(C1,C2) -> 0

Therefore between 1000x1000 and 2000x2000 somethign happen.

Matlab version:
7.9.0.529 (R2009b)
Operating System: Microsoft Windows XP Version 5.1 (Build 2600: Service Pack 3)
Java VM Version: Java 1.6.0_12-b04 with Sun Microsystems Inc. Java HotSpot(TM) Client VM mixed mode
MATLAB Version 7.9 (R2009b)
Simulink Version 7.4 (R2009b)
Curve Fitting Toolbox Version 2.1 (R2009b)
Data Acquisition Toolbox Version 2.15 (R2009b)
Genetic Algorithm and Direct Search Toolbox Version 2.4.2 (R2009b)
MATLAB Compiler Version 4.11 (R2009b)
Optimization Toolbox Version 4.3 (R2009b)
Parallel Computing Toolbox Version 4.2 (R2009b)
Signal Processing Toolbox Version 6.12 (R2009b)
Spline Toolbox Version 3.3.7 (R2009b)
Statistics Toolbox Version 7.2 (R2009b)
Symbolic Math Toolbox Version 5.3 (R2009b)

Concernignt the system:
Intel(R) Core(TM) 2 Duo CPU
T9300 @ 2.50GHz
2.49GHz, 3.50GB of RAM
Physical Address Extension

"Sebastiaan " <s.breedveld@erasmusmc.REMOVE.BOO.BOO.nl> wrote in message <hak4e0$4mf$1@fred.mathworks.com>...
> Any updates on this subject so far?
>
>
> "Bruno Luong" <b.luong@fogale.findmycountry> wrote in message <h9r54u$m5o$1@fred.mathworks.com>...
> >
> > >
> > > I can reproduce this also
> > > XP Sp2 2 Core duo
> > >
> > > >> C1(50,50)
> > >
> > > ans =
> > >
> > > 492.3313
> > >
> > > >> C2(50,50)
> > >
> > > ans =
> > >
> > > 493.1254
> >
> > Any error significantly larger than eps(1)*2000 (=4.4409e-013) is VERY suspicious. It seems like a Bug indeed.
> >
> > The question is: why I'm one of the lucky persons (hello anyone else out there?) who is not affected.
> >
> > Bruno

If I may add an observation, it seems that differences between matrices are close to Gaussian.

Try:
Nel=1000;
A=rand(Nel,Nel);
B=rand(Nel,Nel);
n=maxnumcompthreads(1);
C1=A*B;
maxnumcompthreads(2);
C2=A*B;
maxnumcompthreads(n);
normplot(C1(:)-C2(:))

Interesting but bad...

Moreover, the following code shows the behaviour on my machine when changing Nel...it is very regular...

sigma_diff=[];
Nel_vect=[1000:10:2000];
for jel=1:length(Nel_vect),
  Nel=Nel_vect(jel);
  A=rand(Nel,Nel);
  B=rand(Nel,Nel);
  n=maxnumcompthreads(1);
  C1=A*B;
  maxnumcompthreads(2);
  C2=A*B;
  maxnumcompthreads(n);
  sigma_diff=[sigma_diff,std(C1(:)-C2(:))];
end;
plot(Nel_vect,sigma_diff)

Bye,
Gabriele

"Gabriele " <ruga.ANTI@SPAM.libero.it> wrote in message <hal2n7$62l$1@fred.mathworks.com>...
> I can give my example where the problem occurs when passing from 1000x1000 to 2000x2000:
>
> Code:
> Nel=500;
> A=rand(Nel,Nel);
> B=rand(Nel,Nel);
> n=maxnumcompthreads(1);
> C1=A*B;
> maxnumcompthreads(2);
> C2=A*B;
> maxnumcompthreads(n);
> isequal(C1,C2)
>
> %Result: isequal(C1,C2) -> 1
>
> %--------------
>
> Nel=1000;
> A=rand(Nel,Nel);
> B=rand(Nel,Nel);
> n=maxnumcompthreads(1);
> C1=A*B;
> maxnumcompthreads(2);
> C2=A*B;
> maxnumcompthreads(n);
> isequal(C1,C2)
>
> %Result: isequal(C1,C2) -> 1
>
> %------------------
>
> Nel=2000;
> A=rand(Nel,Nel);
> B=rand(Nel,Nel);
> n=maxnumcompthreads(1);
> C1=A*B;
> maxnumcompthreads(2);
> C2=A*B;
> maxnumcompthreads(n);
> isequal(C1,C2)
>
> %Result: isequal(C1,C2) -> 0
>
> Therefore between 1000x1000 and 2000x2000 somethign happen.
>
> Matlab version:
> 7.9.0.529 (R2009b)
> Operating System: Microsoft Windows XP Version 5.1 (Build 2600: Service Pack 3)
> Java VM Version: Java 1.6.0_12-b04 with Sun Microsystems Inc. Java HotSpot(TM) Client VM mixed mode
> MATLAB Version 7.9 (R2009b)
> Simulink Version 7.4 (R2009b)
> Curve Fitting Toolbox Version 2.1 (R2009b)
> Data Acquisition Toolbox Version 2.15 (R2009b)
> Genetic Algorithm and Direct Search Toolbox Version 2.4.2 (R2009b)
> MATLAB Compiler Version 4.11 (R2009b)
> Optimization Toolbox Version 4.3 (R2009b)
> Parallel Computing Toolbox Version 4.2 (R2009b)
> Signal Processing Toolbox Version 6.12 (R2009b)
> Spline Toolbox Version 3.3.7 (R2009b)
> Statistics Toolbox Version 7.2 (R2009b)
> Symbolic Math Toolbox Version 5.3 (R2009b)
>
> Concernignt the system:
> Intel(R) Core(TM) 2 Duo CPU
> T9300 @ 2.50GHz
> 2.49GHz, 3.50GB of RAM
> Physical Address Extension
>
> "Sebastiaan " <s.breedveld@erasmusmc.REMOVE.BOO.BOO.nl> wrote in message <hak4e0$4mf$1@fred.mathworks.com>...
> > Any updates on this subject so far?
> >
> >
> > "Bruno Luong" <b.luong@fogale.findmycountry> wrote in message <h9r54u$m5o$1@fred.mathworks.com>...
> > >
> > > >
> > > > I can reproduce this also
> > > > XP Sp2 2 Core duo
> > > >
> > > > >> C1(50,50)
> > > >
> > > > ans =
> > > >
> > > > 492.3313
> > > >
> > > > >> C2(50,50)
> > > >
> > > > ans =
> > > >
> > > > 493.1254
> > >
> > > Any error significantly larger than eps(1)*2000 (=4.4409e-013) is VERY suspicious. It seems like a Bug indeed.
> > >
> > > The question is: why I'm one of the lucky persons (hello anyone else out there?) who is not affected.
> > >
> > > Bruno

Hi all,

I can now reproduce the problem with one of our machines.

My team has created a bug report, report no. 583308. To see the latest
update/news with this bug, you can make this bug one of your watched bugs.

To view the bug report, you will need to log in.

http://www.mathworks.com/support/bugreports/

---Bob.


"Sebastiaan " <s.breedveld@erasmusmc.REMOVE.BOO.BOO.nl> wrote in message
news:h9se5e$nae$1@fred.mathworks.com...
> "Bruno Luong" <b.luong@fogale.findmycountry> wrote in message
> <h9saub$pik$1@fred.mathworks.com>...
>> My Dell (Intel(R) Core(TM)2 Duo CPU E8500 @ 3.16GHz) does not seem to be
>> affected by the bug.
>>
> Another test from me:
> MATLAB Version 7.8.0.347 (R2009a)
> Operating System: Microsoft Windows XP Version 5.1 (Build 2600: Service
> Pack 3)
> Java VM Version: Java 1.6.0_04-b12 with Sun Microsystems Inc. Java
> HotSpot(TM) Client VM mixed mode
>
> Core 2 Duo, E8400 3GHz
>
> Works fine.
>

Hi Gabriele,

Due to numerical errors, the matrices are 'allowed' to difference. The problem depicted in this thread is that the difference is too large. What is:

max(abs(C1(:)-C2(:)))

Sebastiaan

"Gabriele " <ruga.ANTI@SPAM.libero.it> wrote in message <hal4di$sqi$1@fred.mathworks.com>...
> If I may add an observation, it seems that differences between matrices are close to Gaussian.
>
> Try:
> Nel=1000;
> A=rand(Nel,Nel);
> B=rand(Nel,Nel);
> n=maxnumcompthreads(1);
> C1=A*B;
> maxnumcompthreads(2);
> C2=A*B;
> maxnumcompthreads(n);
> normplot(C1(:)-C2(:))
>
> Interesting but bad...
>
> Moreover, the following code shows the behaviour on my machine when changing Nel...it is very regular...
>
> sigma_diff=[];
> Nel_vect=[1000:10:2000];
> for jel=1:length(Nel_vect),
> Nel=Nel_vect(jel);
> A=rand(Nel,Nel);
> B=rand(Nel,Nel);
> n=maxnumcompthreads(1);
> C1=A*B;
> maxnumcompthreads(2);
> C2=A*B;
> maxnumcompthreads(n);
> sigma_diff=[sigma_diff,std(C1(:)-C2(:))];
> end;
> plot(Nel_vect,sigma_diff)
>
> Bye,
> Gabriele
>

Hi Sebastian,
of course the problem is also in my case that differences are too large. Instead of using the maximum difference, I've just used the standard deviation to measure the magnitude of the differences.

Anyway, using the following code:
Nel=2000;
A=rand(Nel,Nel);
B=rand(Nel,Nel);
n=maxnumcompthreads(1);
C1=A*B;
maxnumcompthreads(2);
C2=A*B;
maxnumcompthreads(n);

I get from max(abs(C1(:)-C2(:)))
18.4028

and from std(C1(:)-C2(:))
3.3376

And this is extremely large!!!

What is mathworks saying about this?

Bye
Gabriele

"Sebastiaan " <s.breedveld@erasmusmc.REMOVE.BOO.BOO.nl> wrote in message <hamq31$prq$1@fred.mathworks.com>...
> Hi Gabriele,
>
> Due to numerical errors, the matrices are 'allowed' to difference. The problem depicted in this thread is that the difference is too large. What is:
>
> max(abs(C1(:)-C2(:)))
>
> Sebastiaan
>
> "Gabriele " <ruga.ANTI@SPAM.libero.it> wrote in message <hal4di$sqi$1@fred.mathworks.com>...
> > If I may add an observation, it seems that differences between matrices are close to Gaussian.
> >
> > Try:
> > Nel=1000;
> > A=rand(Nel,Nel);
> > B=rand(Nel,Nel);
> > n=maxnumcompthreads(1);
> > C1=A*B;
> > maxnumcompthreads(2);
> > C2=A*B;
> > maxnumcompthreads(n);
> > normplot(C1(:)-C2(:))
> >
> > Interesting but bad...
> >
> > Moreover, the following code shows the behaviour on my machine when changing Nel...it is very regular...
> >
> > sigma_diff=[];
> > Nel_vect=[1000:10:2000];
> > for jel=1:length(Nel_vect),
> > Nel=Nel_vect(jel);
> > A=rand(Nel,Nel);
> > B=rand(Nel,Nel);
> > n=maxnumcompthreads(1);
> > C1=A*B;
> > maxnumcompthreads(2);
> > C2=A*B;
> > maxnumcompthreads(n);
> > sigma_diff=[sigma_diff,std(C1(:)-C2(:))];
> > end;
> > plot(Nel_vect,sigma_diff)
> >
> > Bye,
> > Gabriele
> >

"Gabriele " <ruga.ANTI@SPAM.libero.it> wrote in message <hams2p$ekv$1@fred.mathworks.com>...

>
> What is mathworks saying about this?

Don't you see Bobby Cheng's post above?

Bruno

"Gabriele " <ruga.ANTI@SPAM.libero.it> wrote in message <hams2p$ekv$1@fred.mathworks.com>...
> Hi Sebastian,
> of course the problem is also in my case that differences are too large. Instead of using the maximum difference, I've just used the standard deviation to measure the magnitude of the differences.
>
> Anyway, using the following code:
> Nel=2000;
> A=rand(Nel,Nel);
> B=rand(Nel,Nel);
> n=maxnumcompthreads(1);
> C1=A*B;
> maxnumcompthreads(2);
> C2=A*B;
> maxnumcompthreads(n);
>
> I get from max(abs(C1(:)-C2(:)))
> 18.4028
>
> and from std(C1(:)-C2(:))
> 3.3376
>
> And this is extremely large!!!
>
> What is mathworks saying about this?

That they want as much information as possible :)

What is your Matlab version, operating system and (exact) CPU model?

Sebastiaan

"Sebastiaan " <s.breedveld@erasmusmc.REMOVE.BOO.BOO.nl> wrote in message <hamtn9$crf$1@fred.mathworks.com>...

> > and from std(C1(:)-C2(:))
> > 3.3376
> >
> > And this is extremely large!!!
> >
> > What is mathworks saying about this?
>
> That they want as much information as possible :)
>
> What is your Matlab version, operating system and (exact) CPU model?
>
> Sebastiaan

As already written for the CPU:
Interl Core 2 Duo CPU
T9300 @ 2.5GHz

For the version:

-------------------------------------------------------------------------------------
MATLAB Version 7.9.0.529 (R2009b)

Operating System: Microsoft Windows XP Version 5.1 (Build 2600: Service Pack 3)
Java VM Version: Java 1.6.0_12-b04 with Sun Microsystems Inc. Java HotSpot(TM) Client VM mixed mode
-------------------------------------------------------------------------------------
MATLAB Version 7.9 (R2009b)
Simulink Version 7.4 (R2009b)
Curve Fitting Toolbox Version 2.1 (R2009b)
Data Acquisition Toolbox Version 2.15 (R2009b)
Genetic Algorithm and Direct Search Toolbox Version 2.4.2 (R2009b)
MATLAB Compiler Version 4.11 (R2009b)
Optimization Toolbox Version 4.3 (R2009b)
Parallel Computing Toolbox Version 4.2 (R2009b)
Signal Processing Toolbox Version 6.12 (R2009b)
Spline Toolbox Version 3.3.7 (R2009b)
Statistics Toolbox Version 7.2 (R2009b)
Symbolic Math Toolbox Version 5.3 (R2009b)

Bye,
Gabriele

> As already written for the CPU:
Sorry, I overlooked it.

Summarized from this thread, three people have reported problems so far, all 32 bit versions:

Victor kasaksha:
MATLAB Version 7.8.0.347 (R2009a)
Operating System: Linux 2.6.27.29-0.1-pae #1 SMP 2009-08-15 17:53:59 +0200 i686
Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz

Budias Aao:
MATLAB Version 7.9.0.529 (R2009b)
Operating System: Microsoft Windows Vista Version 6.1 (Build 7600)
Intel Core 2 Duo, T 9300 @2.50GHz, 797 MHz, 1.98 GB of RAM

Gabriele:
Matlab version 7.9.0.529 (R2009b)
Operating System: Microsoft Windows XP Version 5.1 (Build 2600: Service Pack 3)
Intel(R) Core(TM) 2 Duo CPU, T9300 @ 2.50GHz, 2.49GHz, 3.50GB of RAM, Physical Address Extension

Please correct me.

The only agreement here is the T9300, but what about the E8400?

Sebastiaan

"Bruno Luong" <b.luong@fogale.findmycountry> wrote in message
news:hamtc2$i56$1@fred.mathworks.com...
> "Gabriele " <ruga.ANTI@SPAM.libero.it> wrote in message
> <hams2p$ekv$1@fred.mathworks.com>...
>
>>
>> What is mathworks saying about this?
>
> Don't you see Bobby Cheng's post above?

For those of you who may have missed it, Bobby's post is:

http://www.mathworks.com/matlabcentral/newsreader/view_thread/261541#685778

The short version: we have reproduced the problem and have captured it as
bug report 583308 on the support website; watch that bug report for more
information.

--
Steve Lord
slord@mathworks.com
comp.soft-sys.matlab (CSSM) FAQ: http://matlabwiki.mathworks.com/MATLAB_FAQ

We suspect that processors that have sse4 instruction will encounter this
problem. But this is just a guess.

---Bob.


"Sebastiaan " <s.breedveld@erasmusmc.REMOVE.BOO.BOO.nl> wrote in message
news:hanbc5$hd5$1@fred.mathworks.com...
>> As already written for the CPU:
> Sorry, I overlooked it.
>
> Summarized from this thread, three people have reported problems so far,
> all 32 bit versions:
>
> Victor kasaksha:
> MATLAB Version 7.8.0.347 (R2009a)
> Operating System: Linux 2.6.27.29-0.1-pae #1 SMP 2009-08-15 17:53:59 +0200
> i686
> Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz
>
> Budias Aao:
> MATLAB Version 7.9.0.529 (R2009b)
> Operating System: Microsoft Windows Vista Version 6.1 (Build 7600)
> Intel Core 2 Duo, T 9300 @2.50GHz, 797 MHz, 1.98 GB of RAM
>
> Gabriele:
> Matlab version 7.9.0.529 (R2009b)
> Operating System: Microsoft Windows XP Version 5.1 (Build 2600: Service
> Pack 3)
> Intel(R) Core(TM) 2 Duo CPU, T9300 @ 2.50GHz, 2.49GHz, 3.50GB of RAM,
> Physical Address Extension
>
> Please correct me.
>
> The only agreement here is the T9300, but what about the E8400?
>
> Sebastiaan
>

On Oct 9, 5:47 am, "Sebastiaan "
<s.breedv...@erasmusmc.REMOVE.BOO.BOO.nl> wrote:
> > As already written for the CPU:
>
> Sorry, I overlooked it.
>
> Summarized from this thread, three people have reported problems so far, all 32 bit versions:
>
> Victor kasaksha:
> MATLAB Version 7.8.0.347 (R2009a)
> Operating System: Linux 2.6.27.29-0.1-pae #1 SMP 2009-08-15 17:53:59 +0200 i686
> Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz
>
> Budias Aao:
> MATLAB Version 7.9.0.529 (R2009b)
> Operating System: Microsoft Windows Vista Version 6.1 (Build 7600)
> Intel Core 2 Duo, T 9300 @2.50GHz, 797 MHz, 1.98 GB of RAM
>
> Gabriele:
> Matlab version 7.9.0.529 (R2009b)
> Operating System: Microsoft Windows XP Version 5.1 (Build 2600: Service Pack 3)
> Intel(R) Core(TM) 2 Duo CPU, T9300 @ 2.50GHz, 2.49GHz, 3.50GB of RAM, Physical Address Extension
>
> Please correct me.
>
> The only agreement here is the T9300, but what about the E8400?
>
> Sebastiaan

Well, Bruno blew my response off, but I am getting similar answers to
the others who show buggy returns.
And again:
MATLAB Version 7.9.0.529 (R2009b)
OS: Microsoft Windows XP Professional Version 2002 Service Pack 2
Intel(R) Core(TM)2 Due CPU E8600 @ 3.33GHz 3.32 GHz, 3.25 GB RAM

But, as Bobby said: this problem appears to be on 32bit machines,
which partially explains why I get the same results. (But still odd as
to why Bruno can't even on a 32 bit machine...)

By the way. I like the bug work around : P Hard thought put into it?

-Nathan

My solution to this bug:

Use some other BLAS-library as Intel MKL, what is standard used under Matlab. I tested for example with GotoBla2 and it works fine with it. The GotoBlas is almost as fast as Intel MKL, but it seems that this bug is away.

On Linux Machines:
1. Download GotoBlas2 and install it
2. Bash terminal: export BLAS_VERSION=pathtoGotoBlas2/libgoto2.so
3. The same terminal: matlab

You can of course set this varible in a bash script to automate your matlab call.

I think on windows machines it is the same way. You must compile gotoBlas2 for your machine and then setting the system variable BLAS_VERSION you can repair your matlab :-)

It would be interesting if somebody test it with ATLAS (parallelized)!?!

Best Regards
Victor

A patch has been released. The patch can obtained through the contact support. More detail in:

http://www.mathworks.com/support/bugreports/583308

Bruno

"Victor kasaksha" <viphe@mail.ru> wrote in message <h9f9u0$elc$1@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?
>
> Thank you all
> Viktor
>
> -------------------------------------------------------------------------------------
> MATLAB Version 7.8.0.347 (R2009a)
> MATLAB License Number: 46423
> Operating System: Linux 2.6.27.29-0.1-pae #1 SMP 2009-08-15 17:53:59 +0200 i686
> Java VM Version: Java 1.6.0_04-b12 with Sun Microsystems Inc. Java HotSpot(TM) Client VM mixed mode
> -------------------------------------------------------------------------------------
> MATLAB Version 7.8 (R2009a)
> Simulink Version 7.3 (R2009a)
> Bioinformatics Toolbox Version 3.3 (R2009a)
> Communications Blockset Version 4.2 (R2009a)
> Communications Toolbox Version 4.3 (R2009a)
> Control System Toolbox Version 8.3 (R2009a)
> Conversion to SeDuMi Version routines for reading in problems from SDPPack,
> Curve Fitting Toolbox Version 2.0 (R2009a)
> Fixed-Point Toolbox Version 2.4 (R2009a)
> Fuzzy Logic Toolbox Version 2.2.9 (R2009a)
> Genetic Algorithm and Direct Search Toolbox Version 2.4.1 (R2009a)
> INTLAB INTerval LABoratory Version 5.5 07-May-2008 780 files, 690 m-files, 25,517 lines of Matlab
> Image Processing Toolbox Version 6.3 (R2009a)
> Instrument Control Toolbox Version 2.8 (R2009a)
> MATLAB Builder JA Version 2.0.3 (R2009a)
> MATLAB Compiler Version 4.10 (R2009a)
> Mapping Toolbox Version 2.7.2 (R2009a)
> Model Predictive Control Toolbox Version 3.1 (R2009a)
> Neural Network Toolbox Version 6.0.2 (R2009a)
> Optimization Toolbox Version 4.2 (R2009a)
> Parallel Computing Toolbox Version 4.1 (R2009a)
> Partial Differential Equation Toolbox Version 1.0.14 (R2009a)
> RF Blockset Version 2.4 (R2009a)
> RF Toolbox Version 2.5 (R2009a)
> Real-Time Workshop Version 7.3 (R2009a)
> Real-Time Workshop Embedded Coder Version 5.3 (R2009a)
> Regularization Tools Version
http://www.wikio.com/article/bad-credit-payday-loans-176415445
> Robust Control Toolbox Version 3.3.3 (R2009a)
> Signal Processing Blockset Version 6.9 (R2009a)
> Signal Processing Toolbox Version 6.11 (R2009a)
> SimElectronics Version 1.2 (R2009a)
> SimMechanics Version 3.1 (R2009a)
> SimPowerSystems Version 5.1 (R2009a)
> Simscape Version 3.1 (R2009a)
> Simulink Control Design Version 2.5 (R2009a)
> Simulink Design Optimization Version 1.0 (R2009a)
> Simulink Fixed Point Version 6.1 (R2009a)
> Spline Toolbox Version 3.3.6 (R2009a)
> Stateflow Version 7.3 (R2009a)
> Stateflow Coder Version 7.3 (R2009a)
> Statistics Toolbox Version 7.1 (R2009a)
> Symbolic Math Toolbox Version 5.2 (R2009a)
> System Identification Toolbox Version 7.3 (R2009a)
> Video and Image Processing Blockset Version 2.7 (R2009a)
> Wavelet Toolbox Version 4.4 (R2009a)
> >>