From: Georg Baum (Georg.Baum_at_[hidden])
Date: 2006-07-04 13:30:47
Am Dienstag, 4. Juli 2006 09:29 schrieb Hatger, Carsten:
> hi all,
>
> I'm not quite sure whether this is the right place where to put my
question, lets give it a try.
Yes, this is the right place.
> I think there is a macro (re-)definition bug in the ublas bindings
concerning clapack, lapack & atlas.
>
> Consider a class that uses both clapack and lapack routines. If matrices
storage layout is mixed (which ist a must, then), either row-based for
proper use with clapack&atlas or column-based for use with lapack and
both headerfiles
> #include <boost/numeric/bindings/atlas/clapack.hpp>
> #include <boost/numeric/bindings/lapack/lapack.hpp>
> are included within one msvc7.1 project the macro
BOOST_NUMERIC_BINDINGS_FORTRAN defaults to true and subsequent checks for
routines using row-major will fail with boost::STATIC_ASSERTION_FAILURE.
>
> However, if the macro BOOST_NUMERIC_BINDINGS_NO_STRUCTURE_CHECK is
defined globally compilation completes sucessfully and resulting code
seems to work as expected.
Can you give a small example that demonstrates the problem?
> Is this by design, my fault (I hope so) or a bug?
I think it is by desgin (don't include both the clapack bindings and the
lapack bindings in one source file).
I don't understand why one would want to mix clapack and lapack: Don't you
need to convert between row major and column major all the time when
doing so?
I always use the lapack bindings (but link against the fortran atlas
library), and that works well for me. The reason for not using clapack is
that I also use other fortran code, so I chose to do everything with
column major matrices.
Georg