|
|
Ublas : |
Subject: Re: [ublas] numeric bindings nrm2 differences
From: Kraus Philipp (philipp.kraus_at_[hidden])
Date: 2011-11-29 08:53:51
Hi Thomas,
great thanks to you (and all other people on the mailing list).
Am 29.11.2011 um 13:53 schrieb Thomas Klimpel:
> Hi Philipp,
>
> There are tests for this functionality, and the blas1 functionality is the one most likely to break on different os/compiler combinations, due to a wide array of return conventions.
>
> If you tell me your fortran and c++ compiler (or whether you use clapack, ATLAS, MKL, ACML, or the optimized OS-X libs), I could tell you the used return convention.
I have compiled the ATLAS and Netlibs' LAPack myself (Atlas 3.9.42, 45, 51 / LAPack 3.4.0). Standard steps like configure --with-netlib-lapack-tarfile, make, make install.
GCC / G++ on OSX:
i686-apple-darwin10-gcc-4.2.1
GNU Fortran (GCC) 4.5.1 20100506
on Gentoo Linux x64
gcc (Gentoo 4.5.3-r1 p1.0, pie-0.4.5) 4.5.3
GNU Fortran (Gentoo 4.5.3-r1 p1.0, pie-0.4.5) 4.5.3
> The opinion of Karl Meerbergen on this issue (in the past) was that his measurements show no advantages of using blas1 routines over normal C++ code optimized by a compiler. So he questioned whether trying to support this chaos of return conventions is even necessary. (Is there any alternative to handling these differences via macros that the user has to define in order to indicate the compiler/library combination used?)
If I understand this correct, I can / should remove the BOOST_NUMERIC_BINDINGS_BLAS_CBLAS flag to test it? See my other post to Rutger's answer. I'm using the flag at the moment.
> In conclusion, even so it should be possible to find out what goes wrong in your case, avoiding blas1 calls might be the better option for you. (Despite this, I still think that it’s a good thing that the bindings try to be able to also bind “challenging” fortran function signatures.)
The problem exists if I updated the libraries. I have tested ATLAS back to .42 version, but I have found a version that does not creates the problem, but I don't remember the version.
How can I found out, which call goes wrong?
Thanks
Phil
>
> From: ublas-bounces_at_[hidden] [mailto:ublas-bounces_at_[hidden]] On Behalf Of Kraus Philipp
> Sent: Tuesday, November 29, 2011 12:33 PM
> To: ublas mailing list
> Subject: [ublas] numeric bindings nrm2 differences
>
> Hello I'm using the numeric bindings to call ATLAS / LAPack functions.
> If I use the boost::numeric::bindings::blas::nrm2 method, I get a numeric difference.
>
> I'm running the nrm2 command with a double datatyp I get the values:
> 1,89705246692049
> 1,34040265444338
> 1,51170579623667
> 1,83956751945403
>
> If I run the same data values on Matlab (Matlab uses also Boost & ATLAS / LAPack) I get:
> 2,04932000000000
> 1,45494000000000
> 1,61857000000000
> 2,02891000000000
>
> Does the nrm2 call delegate to the ATLAS nrm2 (cblas) ? So the numeric binding is a wrapper structure only for the ATLAS calls?
> I try to find out which part creates this numeric difference, because the difference creates a big problem within my algorithm
> I have tested the code under OSX and Linux x64 and on both systems the problem is still be found.
>
> Thanks a lot
> _______________________________________________
> ublas mailing list
> ublas_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/ublas
> Sent to: philipp.kraus_at_[hidden]