Bug#419556: ambigous results in matrix multipliication
Package: Octave2.9
Status: install ok installed
Priority: optional
Section: math
Installed-Size: 26220
Maintainer: Debian Octave Group <[EMAIL PROTECTED]>
Architecture: i386
Version: 2.9.10-3
Severity: Important
One expects that a matrix multiplication (A*B)' gives the same result than for
(B'*A'). This is not the case for the debian octave package (tested with
2.9.10-3 and 2.1.73-13)
Here is the test script:
repmat(0,2)*repmat(NaN,2)
repmat(NaN,2)*repmat(0,2)
repmat(0,2)*repmat(inf,2)
repmat(inf,2)*repmat(0,2)
version
octave_config_info('BLAS_LIBS')
octave2.9:27> repmat(0,2)*repmat(NaN,2)
ans =
NaN NaN
NaN NaN
octave2.9:28> repmat(NaN,2)*repmat(0,2)
ans =
0 0
0 0
octave2.9:29> repmat(0,2)*repmat(inf,2)
ans =
NaN NaN
NaN NaN
octave2.9:30> repmat(inf,2)*repmat(0,2)
ans =
0 0
0 0
octave2.9:31> version
ans = 2.9.10
octave2.9:32> octave_config_info('BLAS_LIBS')
ans = -llapack-3 -lblas-3
The problem seems to be in the lapack or blas library. Because this problem
disappears (the result is always NaN) when I compile Octave from the sources
using Atlas. The octae_config_info says
octave:64> version
ans = 2.9.10+
octave:65> octave_config_info('BLAS_LIBS')
ans = -llapack -lcblas -lf77blas -latlas
A related problem has been also discussed here and here
http://velveeta.che.wisc.edu/octave/lists/bug-octave/2001/104
http://velveeta.che.wisc.edu/octave/lists/bug-octave/2002/293
Obviously, it is not fixed for the debian package.
Alois
--
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#419556: [Pkg-octave-devel] Bug#419556: ambigous results in matrix multipliication
Am Montag, 23. April 2007 22:01:44 schrieb Alois Schlögl: > Thomas Weber wrote: > > I guess the best "fix" for this problem is installing one of the atlas3-* > > packages. > > Yes, I agree. Setting the dependences accordingly would solve the > problem for the debian users of octave. Well, we actually have atlas3-base | lapack3 | liblapack.so.3 as Depends-line. So you should get atlas3-base if you install Octave and only if it's not available, one of the alternatives. The problem is: if you already have lapack installed, atlas3 won't be installed. Do you have OpenOffice.org on the same machine? Regarding the fix for dgemm: sorry, but dgemm is a known and documented reference implementation. I don't think we should tinker with that. Regards Thomas
Bug#419556: [Pkg-octave-devel] Bug#419556: ambigous results in matrix multipliication
Thomas Weber wrote: Am Montag, 23. April 2007 22:01:44 schrieb Alois Schlögl: Thomas Weber wrote: I guess the best "fix" for this problem is installing one of the atlas3-* packages. Yes, I agree. Setting the dependences accordingly would solve the problem for the debian users of octave. Well, we actually have atlas3-base | lapack3 | liblapack.so.3 as Depends-line. So you should get atlas3-base if you install Octave and only if it's not available, one of the alternatives. The problem is: if you already have lapack installed, atlas3 won't be installed. Do you have OpenOffice.org on the same machine? Yes, OO is installed. Regarding the fix for dgemm: sorry, but dgemm is a known and documented reference implementation. I don't think we should tinker with that. Following that line of thinking, the consequence is to change the list of dependencies in such a way that atlas3-* must be used and lapack is not a viable alternative anymore. Regards Thomas Regards, Alois -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#419556: [Pkg-octave-devel] Bug#419556: ambigous results in matrix multipliication
Am Mittwoch, 25. April 2007 21:57 schrieb Alois Schlögl: > > The problem is: if you already have lapack installed, atlas3 won't be > > installed. Do you have OpenOffice.org on the same machine? > > Yes, OO is installed. openoffice.org-calc depends on libufsparse which depends on lapack3 | atlas3-base So if you install OO.org before Octave, you will get lapack3. I wonder if libufsparse should list atlas3-base before lapack3. > > Regarding the fix for dgemm: sorry, but dgemm is a known and documented > > reference implementation. I don't think we should tinker with that. > > Following that line of thinking, the consequence is to change the list > of dependencies in such a way that atlas3-* must be used and lapack is > not a viable alternative anymore. I'm not happy with that. It's possible to use Octave with a specific BLAS-library not provided by Debian (for example Goto Blas). And in reality, atlas3-base is not what you want -- you want one of the tuned atlas3-sseX or atlas3-3dnow packages. Rafael, should we add a Recommends: atlas3-base to Octave? Regards Thomas
Bug#419556: [Pkg-octave-devel] Bug#419556: ambigous results in matrix multipliication
* Thomas Weber <[EMAIL PROTECTED]> [2007-04-25 22:19]: > Rafael, should we add a > Recommends: atlas3-base > to Octave? Okay with me. -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#419556: [Pkg-octave-devel] Bug#419556: ambigous results in matrix multipliication
Hi,
Am Montag, 16. April 2007 17:32 schrieb Alois Schloegl:
> One expects that a matrix multiplication (A*B)' gives the same result than
> for (B'*A'). This is not the case for the debian octave package (tested
> with 2.9.10-3 and 2.1.73-13)
>
> Here is the test script:
>
> repmat(0,2)*repmat(NaN,2)
> repmat(NaN,2)*repmat(0,2)
> repmat(0,2)*repmat(inf,2)
> repmat(inf,2)*repmat(0,2)
> version
> octave_config_info('BLAS_LIBS')
I take it for granted that you didn't have ATLAS installed. Is this correct?
Unless I'm mistaken, the reference implementation of dgemm is supposed to do
exactly this, see
http://velveeta.che.wisc.edu/octave/lists/bug-octave/2002/310
> The problem seems to be in the lapack or blas library. Because this problem
> disappears (the result is always NaN) when I compile Octave from the
> sources using Atlas.
I guess the best "fix" for this problem is installing one of the atlas3-*
packages.
Regards
Thomas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#419556: [Pkg-octave-devel] Bug#419556: ambigous results in matrix multipliication
Original-Nachricht
Datum: Mon, 16 Apr 2007 21:38:12 +0200
Von: Thomas Weber <[EMAIL PROTECTED]>
An: Alois Schloegl <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Betreff: Re: [Pkg-octave-devel] Bug#419556: ambigous results in matrix
multipliication
> Hi,
>
> Am Montag, 16. April 2007 17:32 schrieb Alois Schloegl:
> > One expects that a matrix multiplication (A*B)' gives the same result
> than
> > for (B'*A'). This is not the case for the debian octave package (tested
> > with 2.9.10-3 and 2.1.73-13)
> >
> > Here is the test script:
> >
> > repmat(0,2)*repmat(NaN,2)
> > repmat(NaN,2)*repmat(0,2)
> > repmat(0,2)*repmat(inf,2)
> > repmat(inf,2)*repmat(0,2)
> > version
> > octave_config_info('BLAS_LIBS')
>
> I take it for granted that you didn't have ATLAS installed. Is this
> correct?
Actually, it was the same machine that I used for compiling Octave with Atlas.
So atlas-base-dev (which requires also atlas-base) was installed when I tested
Octave 2.9.10-3.
>
> Unless I'm mistaken, the reference implementation of dgemm is supposed to
> do
> exactly this, see
> http://velveeta.che.wisc.edu/octave/lists/bug-octave/2002/310
IMHO, this is a bug (and not a feature) of dgemm. Especially, because (A*B)' is
not the same as (B'*A').
octave:16> [nan nan]*[0;0]
ans = 0
octave:17> [0,0]*[nan nan]'
ans = NaN
octave:20> [0,0]*[inf inf]'
ans = NaN
octave:21> [inf inf]*[0;0]
ans = 0
>
> > The problem seems to be in the lapack or blas library. Because this
> problem
> > disappears (the result is always NaN) when I compile Octave from the
> > sources using Atlas.
>
> I guess the best "fix" for this problem is installing one of the atlas3-*
> packages.
>
Do you mean that installing atlas3-* besides the debian octave package solves
the problem? I do not think so, because the machine I used had Atlas installed.
If you mean, that atlas3-* should be installed when the Octave package is
compiled for debian, yes I agree to that. Perhaps, the dependency between
Octave and atlas-* need to be changed, such that atlas is mandatory instead of
one of several alternatives.
> Regards
> Thomas
Regards,
Alois
--
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#419556: [Pkg-octave-devel] Bug#419556: ambigous results in matrix multipliication
Thomas Weber wrote:
Hi,
Am Montag, 16. April 2007 17:32 schrieb Alois Schloegl:
One expects that a matrix multiplication (A*B)' gives the same result than
for (B'*A'). This is not the case for the debian octave package (tested
with 2.9.10-3 and 2.1.73-13)
Here is the test script:
repmat(0,2)*repmat(NaN,2)
repmat(NaN,2)*repmat(0,2)
repmat(0,2)*repmat(inf,2)
repmat(inf,2)*repmat(0,2)
version
octave_config_info('BLAS_LIBS')
I take it for granted that you didn't have ATLAS installed. Is this correct?
The answer in my last mail was just a guess (I did not have access to
the same machine). Now, I was able to check this on a different machine.
Yes, I can confirm that the result depends on the fact whether atlas is
installed or not.
Unless I'm mistaken, the reference implementation of dgemm is supposed to do
exactly this, see
http://velveeta.che.wisc.edu/octave/lists/bug-octave/2002/310
The problem seems to be in the lapack or blas library. Because this problem
disappears (the result is always NaN) when I compile Octave from the
sources using Atlas.
I guess the best "fix" for this problem is installing one of the atlas3-*
packages.
Yes, I agree. Setting the dependences accordingly would solve the
problem for the debian users of octave.
Regards
Thomas
Regards,
Alois
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
