-
rwhaley committed patchset 1743 of module AtlasBase to the Automatically Tuned Linear Algebra Soft. CVS repository, changing 1 files.
2010-01-07 19:10:54 UTC by rwhaley
-
rwhaley committed patchset 1742 of module AtlasBase to the Automatically Tuned Linear Algebra Soft. CVS repository, changing 4 files.
2010-01-06 18:14:06 UTC by rwhaley
-
Turns out that getri needs the LU factorization from getrf and doesn't call getrf itself. Once I supply the LU factorization from getrf to getri, the matrix is computed properly.
Thanks,
Vivek.
2010-01-05 22:25:25 UTC by vivekbn
-
I am trying to test out a local build of ATLAS3.8.3 under Linux by inverting a 2x2 upper triangular matrix. When I compute the inverse using trsm I get the correct answer, but when I compute the answer using getri, I get the wrong answer. I am attaching my test code, which creates the 2x2 matrix and makes the calls to the atlas lib.
Here is the output from the program. Any help would be...
2010-01-05 21:33:22 UTC by vivekbn
-
rwhaley committed patchset 1741 of module AtlasBase to the Automatically Tuned Linear Algebra Soft. CVS repository, changing 2 files.
2010-01-05 17:52:01 UTC by rwhaley
-
rwhaley committed patchset 1740 of module AtlasBase to the Automatically Tuned Linear Algebra Soft. CVS repository, changing 4 files.
2010-01-04 20:30:15 UTC by rwhaley
-
rwhaley committed patchset 1739 of module AtlasBase to the Automatically Tuned Linear Algebra Soft. CVS repository, changing 13 files.
2010-01-04 17:36:19 UTC by rwhaley
-
last change on *_ilaenv make hard (impossible) to build cygwin dlls
with the same symbol list of netlib lapack.
Until 3.9.19
liblapack.a was depending on _ATL_ilaenv
(ATL_dgelqf.o, ATL_dgeqrf.o, ATL_dgerqf.o, ATL_sgelqf.o...)
on 3.9.20
liblapack is now depending on _clapack_ilaenv
As I already mentioned, I think the decision to move ilaenv and clapack_ilaenv in the blas is a bad.
2010-01-04 15:40:21 UTC by matzeri
-
Marco,
I have moved this to the feature request queue. I also already mentioned my reasons for the way ilaenv is handled.
The new design you propose is definitely possible. While I hate to have yet another subroutine call in an already long chain, that would satisfy the needed dependencies w/o the ugliness of having a clapack_ routine inside a BLAS library. I need to think on this...
2010-01-04 14:51:27 UTC by rwhaley
-
last change on *_ilaenv make hard (impossible) to build cygwin dlls
with the same symbol list of netlib lapack.
Until 3.9.19
liblapack.a was depending on _ATL_ilaenv
(ATL_dgelqf.o, ATL_dgeqrf.o, ATL_dgerqf.o, ATL_sgelqf.o...)
on 3.9.20
liblapack is now depending on _clapack_ilaenv
As I already mentioned, I think the decision to move ilaenv and clapack_ilaenv in the blas is a bad.
2010-01-04 11:45:07 UTC by matzeri
