Re: [ublas] numeric-bindings: current issues on 64-bit platforms

Subject: Re: [ublas] numeric-bindings: current issues on 64-bit platforms
From: Thomas Klimpel (Thomas.Klimpel_at_[hidden])
Date: 2008-12-03 16:58:33

Thomas Klimpel wrote:
> However, something is still fishy, because the test-script produces the following output on a linux32 system:
> integer_8: 0 f2c_return_conventions: 1
> ireal(-2): -1
> sreal(-2): -1
> dreal(-2): -1
> creal(-2): -1
> zreal(-2): -1
> integer_8: 0 f2c_return_conventions: 0
> ireal(-2): -1
> sreal(-2): -1
> dreal(-2): -1
> creal(-2): 1.4013e-45
> zreal(-2): -1
> integer_8: 0 f2c_return_conventions: 0
> ireal(-2): -1
> sreal(-2): -1
> dreal(-2): -1
> creal(-2): 1.4013e-45
> zreal(-2): -1
> integer_8: 0 f2c_return_conventions: 1
> ireal(-2): -1
> sreal(-2): -1
> dreal(-2): -1
> creal(-2): -1
> zreal(-2): -1
> integer_8: 1 f2c_return_conventions: 0
> ireal(-2): 2147483647
> sreal(-2): -1
> dreal(-2): -1
> creal(-2): 1.4013e-45
> zreal(-2): -1
> integer_8: 1 f2c_return_conventions: 1
> ireal(-2): 2147483647
> sreal(-2): -1
> dreal(-2): -1
> creal(-2): -1
> zreal(-2): -1
> 
> 
> So I still have to find out why linux32 behaves different than I thought it would from the descriptions in the manpage.

The problem is that the Fortran type "complex" is returned as the c99 type "_Complex float". Using "typedef _Complex float fcomplex_t" works fine with gcc on both linux32 and linux64, but I got the impression that it doesn't compile with VC8. Using "typedef std::complex<float> fcomplex_t" doesn't work on linux32. However, using "typedef long long fcomplex_t" works on linux32 and compiles on VC8, but...

I guess the best thing to do is using "config.hpp" to automatically find out whether the detected compiler is known to support _Complex float. Then we can use "typedef _Complex float fcomplex_t" and fall back to "typedef std::complex<float> fcomplex_t" in case "_Complex float" is not supported.

The problem with "ireal(-2): 2147483647" goes away when using "typedef long long integer_t" instead of "typedef std::ptrdiff_t integer_t". However, I don't think that using lapack or blas with 64bit integers but 32bit pointers is useful for any real problem. So we might as well stick with the "portable" version "typedef std::ptrdiff_t integer_t".

Regards,
Thomas