Diagonal test failure on release-0.3 with icc 14.0.1/linux64 build

[jiahao]

Compiling with the instructions in #10181 results in two test failures. One is JuliaMath/openspecfun#30. The other is:

exception on 5: ERROR: assertion failed: |func(D) - func(DM)| <= 3.4332275e-5
  func(D) = 1.048798f0 - 1.5707964f0im
  func(DM) = 1.0487979650497437 - 0.5797938426309308im
  difference = 0.9910025278753558 > 3.4332275e-5
 in read at ./iobuffer.jl:86
 in read at stream.jl:699
 in anonymous at task.jl:837
while loading linalg4.jl, in expression starting on line 263
ERROR: assertion failed: |func(D) - func(DM)| <= 3.4332275e-5
  func(D) = 1.048798f0 - 1.5707964f0im
  func(DM) = 1.0487979650497437 - 0.5797938426309308im
  difference = 0.9910025278753558 > 3.4332275e-5
 in anonymous at task.jl:1367
while loading linalg4.jl, in expression starting on line 263
while loading /home/jiahao/julia-intel/test/runtests.jl, in expression starting on line 39

[tkelman]

This was recently reported by someone else either here or on julia-users, I'm pretty sure it's a complex calling convention difference

[jiahao]

I couldn't find an existing open issue about this failure. I assume you mean this julia-users thread.

[jiahao]

Would your diagnosis have any relevance to the complex tests passing?

[tkelman]

Thank you, that's the one. Are you sure ifort was used to build arpack?

[jiahao]

Yes, ifort is picked up in ARPACK's config.status. However libarpack.a contains symbols from both icc and gfortran.

The failure was in computing logdet on Diagonal matrices so I don't think ARPACK is at fault here.

[tkelman]

Oh right, the arpack test was segfaulting in that julia-users post at the same time as the linalg4 failure. Whoops.

Can you step through the logdet implementations for D vs DM there, see where the discrepancy appears?

[jiahao]

Turns out that both logdet(::Matrix{Complex64}) and logdet(::Diagonal{Complex64}) have problems. The former is not type stable but is numerically correct. The latter gives the wrong answer.

julia> A = Complex64[  -0.821514+0.480765im 
           1.43384+0.671372im 
          0.992773+1.16314im  
        -0.0836201+0.664579im 
         -0.780475-0.2211im   
         -0.757667-1.01613im  
           1.18468-0.0310553im
          0.621789+0.079201im 
          -1.23714+0.0164326im
          0.766273-0.893556im 
          0.685642+0.149939im 
          -2.01473+1.24516im];

julia> D = Diagonal(A); M = full(D); logdet(M) #Note that logdet(::Matrix) is NOT Complex64
1.048797845840454 - 0.5797933657937726im

julia> log(prod(D)) #What the answer should be
1.048798f0 - 0.57979345f0im

The determinant is computed correctly in both formats, i.e, 2.3877575f0 - 1.5636871f0im.

---

It turns out that the problem is that mod2pi in my build produces crazy answers. In this logdet(::Diagonal{<:Complex}) method, the imaginary component is adjusted to produce the correct principal value. This test produces a raw value of 1.0487943f0 + 5.703389f0im before adjustment; after adjustment, the imaginary component is pi/2 to working Float32 precision:

julia> mod2pi(5.703389f0+π)
1.5707964f0

julia> (5.703389f0+π) % 2π
2.5617968400372106

julia> float32(π/2)
1.5707964f0

julia> mod2pi(5.703389+pi) #Similar problem for Float64
1.5707963267948974

julia> 17 % 2π #Some arbitrary number
4.4336293856408275

julia> mod2pi(17.0)
3.141592653589793

[tkelman]

#8799

[jiahao]

The first issue is fixed in #10189 and the second issue is a duplicate of #8799. Closing.

[jdtuck]

I am still seeing this issue in the release-0.3 pulled today, I thought #10200, fixed this. I am using icc version 15.0.2 is the only difference

[jiahao]

No, only half the problem is fixed. The other half is a duplicate of another issue which hasn't been fixed yet.

[garrison]

@jstuck Everything works for me now on release-0.3, as of 7c42e5a. Thanks @tkelman!

[garrison]

Sorry @jstuck, meant to ping @jdtuck here.

[jdtuck]

Thanks, working for me now as well