[Pkg-octave-devel] Re: Sparse + complex arithmetic inconsistency

David Bateman adb014 at gmail.com
Sat Mar 31 14:55:12 UTC 2007


John W. Eaton wrote:
> On 30-Mar-2007, David Bateman wrote:
> 
> | Or a slightly modification
> | 
> | #include <math.h>
> | #include <complex.h>
> | #include <stdio.h>
> | int main(int argc, char *argv[])
> | {
> |   complex double b=1,c=I*1,d = 1+I*1,z = 0.;
> |   // This should produce (inf,0), not (nan,nan).
> |   printf("(%f,%f) / (%f,%f) -> (%f,%f)\n",
> |          creal(b),cimag(b),creal(z),cimag(z),creal(b/z),cimag(b/z));
> |   // This should produce (0,inf), not (nan,nan).
> |   printf("(%f,%f) / (%f,%f) -> (%f,%f)\n",
> |          creal(c),cimag(c),creal(z),cimag(z),creal(c/z),cimag(c/z));
> |   // This should produce (inf,inf), not (nan,nan).
> |   printf("(%f,%f) / (%f,%f) -> (%f,%f)\n",
> |          creal(d),cimag(d),creal(z),cimag(z),creal(d/z),cimag(d/z));
> |   return 0;
> | }
> | 
> | that all return (nan,nan) for me.
> 
> Here is what I see:
> 
> $ gcc foo.c
> $ ./a.out
> (1.000000,0.000000) / (0.000000,0.000000) -> (nan,nan)
> (0.000000,1.000000) / (0.000000,0.000000) -> (nan,nan)
> (1.000000,1.000000) / (0.000000,0.000000) -> (nan,nan)
> $ gcc -O2 foo.c
> $ ./a.out
> (1.000000,0.000000) / (0.000000,0.000000) -> (inf,0.000000)
> (0.000000,1.000000) / (0.000000,0.000000) -> (0.000000,inf)
> (1.000000,1.000000) / (0.000000,0.000000) -> (inf,inf)
> $ gcc -v
> Using built-in specs.
> Target: i486-linux-gnu
> Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --with-tune=i686 --enable-checking=release i486-linux-gnu
> Thread model: posix
> gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
> 
> Is that acceptable behavior or a bug?
> 
> I seem to recall this problem coming up before, and we may have even
> discussed it on the bug or maintainers list (the topic just seems
> familiar; I haven't tried to find the thread in the archives).
> 
> jwe
> 
> 

Michael reported it a few months ago, together with the issue that with
gcc/g++ 4.1 it is optimizer flag dependent. With gcc 4.0.1 I see
(nan,nan) as a result of all of the operations. See the thread

http://www.nabble.com/Sparse-matrix-problem-tf2844890.html#a8149128

This has been reported to fedora who passed it upstream to GCC, however
its part of a large swath of complex implementation issues, and the fact
that the C99 standard is not very clear on a number of points
surrounding this.. See the threads

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=221319

and then

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30482

which leads to

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24581

and

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28408

Until GCC gets its act together on this one there isn't much we can do.
Note that the fact that Michael reported this means that it is also a
misfeature of MSVC...

D.



More information about the Pkg-octave-devel mailing list