See Travis failure

    From worker 2:       * linalg1
    From worker 3:       * linalg2
exception on 2: ERROR: type: selctg2c: in typeassert, expected Int32, got Int64
 in selctg2c at linalg/lapack.jl:3367
 in gees! at linalg/lapack.jl:3415
 in schurfact at linalg/factorization.jl:694
 in anonymous at no file:198
 in runtests at /private/tmp/julia/share/julia/test/testdefs.jl:5
 in anonymous at multi.jl:852
 in run_work_thunk at multi.jl:603
 in anonymous at task.jl:852
while loading linalg1.jl, in expression starting on line 25

Tests are passing on my machine.

Can anyone reproduce this locally? Not sure what the problem could be.

I think that selctg returns 0 for all pairs of a and b. Couldn't that be the problem? Do you have a reason to define selctg(a, b) = abs(a) == 0.0 ? 1 : 0 like that. E.g. I think the opposite works, i.e. selctg(a, b) = abs(a) != 0.0 ? 1 : 0.

I think the original intention was to match the scipy's results, but it doesn't look like they had it for the complex version. I'm going to try the less than 1 example and see what happens.

Wrote something on this gist.

I want it to grab eigenvalues with modulus less than 1 and put those in the "upper left" of the matrix. They both give me the same matrix, but there are definitely some generalized eigenvalues with modulus less than 1 (can verify with sfd_ns[:values] .* conj(sfd_ns[:values]))

Bump. What's the next step here?

@spencerlyon2

We brought in another LAPACK function that let us order the eigenvalues in the way we wanted and implemented this in PR #9701 which was enough to finish what we wanted to do at that point in time. Obviously, implementing the selctg functionality would be better in the long run.

A few weeks ago, we came across some work done by Dynare.jl that looks like they have already implemented this functionality in their own package -- See this file. Neither of us have had a chance to look at this more closely due to the semester being in full gear, but if what they have works then it is already done and it is just a matter of writing it up.

As @cc7768 noted, I think we can do something similar to what was done here if we want to get this up and running.

I may need to enable this functionality soon, so I may revisit this early next week.

I think we can do better now that we have Ref and it is also possible to avoid the global variable. With Ref we can use normal Julia functions instead of special Julia functions where the arguments are pointers. I've taken a stab in anj/gees. On that branch, you can do

julia> A = randn(5,5);

julia> abs(eigvals(A))
5-element Array{Float64,1}:
 1.72023 
 1.72023 
 1.0195  
 0.704244
 0.101243

julia> testf(x,y) = Int(hypot(x,y) < 1);

julia> abs(schurfact(A, testf)[:values])
5-element Array{Float64,1}:
 0.704244
 0.101243
 1.72023 
 1.72023 
 1.0195

Code has been reorganized quite a lot since this PR, so I am going to assume someone will re-do this if they need it