Infinite recursion of `\` on sparse matices

[yuyichao]

Update: There are multiple problems that cause the original issue. Use this issue to track the most directly related linalg issue. See #283 for the repro. This causes a regression on 0.5 but the same issue is also present on 0.4 in different forms.

Original post,

This is causing WoodburyMatrices.jl tests to freeze.

minimum repro: code_warntype(\, Tuple{Tridiagonal{Float64},SparseMatrixCSC{Float64,Int64}}).

I don't know how long it is going to take but it takes more than five minutes on my laptop. GDB backtrace shows that it is struggling in type inference on some functions (haven't check which function/types it is since the call chain is super deep and it's a little hard to locate the function it got stuck in...).

This seems to be a recent regression. I remember the WoodburyMatrices test was fine on the version of julia I made mlubin/ReverseDiffSparse.jl#22 (15 days ago) but it's not fine on a 10 days old julia 685f1b0 and there's no update to the WoodburyMatrices package within this period. I might do a bisect later.

@timholy This breaks your package's test so you might want to know this.

[yuyichao]

Bisected to 87e26c516853dd395de3c50406076f2d4d7aa413. @andreasnoack

yuyichao% git bisect good 
87e26c516853dd395de3c50406076f2d4d7aa413 is the first bad commit
commit 87e26c516853dd395de3c50406076f2d4d7aa413
Author: Andreas Noack <andreasnoackjensen@gmail.com>
Date:   Sun Nov 1 12:17:31 2015 -0500

    Consolidate the \ methods for sparse and dense and make the necessary adjustment
    to other methods.

    Solve real lhs problems with complex rhs by reinterpreting the rhs.

    Let factorize(SparseMatrixCSC) check for tringular matrices

:040000 040000 9082f51ee65f12eddae7001fc54a93f945110533 4eb784944d856fc2a301943f0421d2cb165c1214 M      base
:040000 040000 4cbaea91f2bf4fe556206914ff723d8b44dd246e eee94036e2f68946d4c8810cefa401ed138b23de M      test
office:~/projects/julia/master
yuyichao% git bisect log 
git bisect start
# good: [505be935c82e31d3ebe1d275a9f88fb8782cdb1d] Merge pull request JuliaLang/julia#13829 from JuliaLang/yyc/precompile-stderr
git bisect good 505be935c82e31d3ebe1d275a9f88fb8782cdb1d
# bad: [685f1b0b5094ed9efbaa109fbeb36d20cdc35285] Merge pull request JuliaLang/julia#13872 from JuliaLang/amitm/rrfix
git bisect bad 685f1b0b5094ed9efbaa109fbeb36d20cdc35285
# bad: [40d46e7146dd5343c91d7df9df080cbd59e253c5] on llvm37, re-disable the frame-pointer-elim optimization so that unwinding and backtraces usually work
git bisect bad 40d46e7146dd5343c91d7df9df080cbd59e253c5
# good: [9fe603724a738fe6289f152c0abea5bfea4f58e6] Fix whitespace error introduced in last commit
git bisect good 9fe603724a738fe6289f152c0abea5bfea4f58e6
# good: [26839d9f95ef01e4e3708a04369bdbea63b0afb2] Merge pull request JuliaLang/julia#13835 from hayd/markdown_spaces
git bisect good 26839d9f95ef01e4e3708a04369bdbea63b0afb2
# bad: [af3e15d37b70a9057c16cef162767ac97d30ba56] Merge pull request JuliaLang/julia#13793 from JuliaLang/anj/sparsesolve
git bisect bad af3e15d37b70a9057c16cef162767ac97d30ba56
# bad: [87e26c516853dd395de3c50406076f2d4d7aa413] Consolidate the \ methods for sparse and dense and make the necessary adjustment to other methods.
git bisect bad 87e26c516853dd395de3c50406076f2d4d7aa413
# good: [81753ccb9d9fc5d8792fa1847bea645d007ebd1d] Use sparse triangular solvers for sparse triangular solves. Fixes JuliaLang/julia#13792.
git bisect good 81753ccb9d9fc5d8792fa1847bea645d007ebd1d
# first bad commit: [87e26c516853dd395de3c50406076f2d4d7aa413] Consolidate the \ methods for sparse and dense and make the necessary adjustment to other methods.

[yuyichao]

Even though this is bisected to a commit that change the definition of \ I guess the type inference should also be more robust and shouldn't fall in an infinite loop in this case?

[andreasnoack]

Yes. I don't think there is anything wrong with the method.

[yuyichao]

I think there are multiple problems here.

1. LowerTriangular(::LowerTriangular{Float64,Tridiagonal{Float64}}) returns LowerTriangular{Float64,LowerTriangular{Float64,Tridiagonal{Float64}}} instead of LowerTriangular{Float64,Tridiagonal{Float64}}. (i.e. it makes a copy that shares the data instead of returing the input directly) I think this is a missing ambiguity warning. Ref Avoid unnecessary conversions of nullables. julia#12424 (comment)
2. Type inference doesn't have a recursion limit and is doing a infinite recursion when trying to speicialize \ with the first parameter being all conbinations of recursive UpperTriangular and LowerTriangular.
3. There doesn't seem to be a appropriate specialization for UpperTriangular/LowerTriangular and SparseMatrixCSC so even though with this particular parameter the dispatch should go to the qrfact, there's a genuine infinite recursion for \(::UpperTriangular, ::SparseMatrixCSC) (and also lower traingular). I'm not super familiar with these but I guess this is a valid argument combination and even if I'm wrong I think this function should raise an appropriate error instead of giving a stack overflow.

I think all three problems needs to be fixed. For this particular case (the WoodburyMatrices test case), 2 should be enough (since it's a tridiagonal matrix) but it will trigger the infinite recursion easily with a slightly tweaked value (when it's upper or lower triangular) so 3 should also be fixed even when we fix the more general issue in typeinf.

[yuyichao]

And to demonstrate point 3

julia> U = sprandn(5, 2, 0.2)
5x2 sparse matrix with 1 Float64 entries:
        [3, 1]  =  1.14495

julia> A2 = UpperTriangular([1. 2. 3. 4. 5.
                             0  1. 0. 0. 0.
                             0  0  1. 0. 0.
                             0  0  0  1. 0.
                             0  0  0  0  1.])
5x5 UpperTriangular{Float64,Array{Float64,2}}:
 1.0  2.0  3.0  4.0  5.0
 0.0  1.0  0.0  0.0  0.0
 0.0  0.0  1.0  0.0  0.0
 0.0  0.0  0.0  1.0  0.0
 0.0  0.0  0.0  0.0  1.0

julia> A2 \ U
ERROR: StackOverflowError:
 in \ at ./linalg/generic.jl:329

edit: this also happens on 0.4

[yuyichao]

I think this particular issue will be fixed when the necessary specialization is provided (since type inference will dispatch it to other methods instead of infinitely recursing on the same method with different types).

I've updated the issue and will open another issue for the general type inference problem. (edit JuliaLang/julia#14009)

[yuyichao]

Also note that when type inference is fixed to deal with these, the inferened type for the current definition would likely be ::Any.

[Mirage10]

In 0.5 dev: A2\U -> infinite loop
In 0.4.1 : A2\U -> StackOverflowError

[andreasnoack]

Thanks for analyzing the issues here. We should probably define a fall back for sparse right hand side with full(B) because it's very unlikely that the solution will be sparse even when both problem matrix and right hand side are sparse, e.g.

julia> Bidiagonal(ones(5), ones(4), false)\eye(5,1)
5x1 Array{Float64,2}:                              
  1.0                                              
 -1.0                                              
  1.0                                              
 -1.0                                              
  1.0                                              

However, there could easily be other situations where some combination of A and B wouldn't be defined so I think it is necessary to have a way to avoid the inifinite loop in inference. Is your fix of 1. enough to avoid it?