Groups 178 of 99+ julia-users › Overriding Methods in Base 9 posts by 3 authors Jared Crean 8/11/15 For a problem I am working on, I need to be able to store explicit zeros in a SparseMatrixCSC. While the storage format supports this, the setindex! method does not. Also, for banded sparse matricies I can define a much more efficient getindex method than the generic one. When I define my own method (importing the one from Base and then creating a method with the same signature as the existing one) I get warnings of the type: Warning: Method definition getindex(Base.SparseMatrix.SparseMatrixCSC{#T<:Any, Ti<:Integer}, Integer, Integer) in module SparseMatrix at sparse/sparsematrix.jl:1232 overwritten in module PDESolverCommon at /users/creanj/.julia/v0.4/PDESolverCommon/src/sparse.jl:63. My question is in what contexts is the method overwritten? In my local context (the REPL session where I use the one I created). Do functions within Base use the one in Base or the local one? Jared Crean Yichao Yu 8/11/15 - show quoted text - Every user of it (including Base) in your current julia session. > > Jared Crean > > Jared Crean 8/11/15 Thanks for the quick reply. Now I am curious, what happens if the old method was inlined in a function compiled before the new method was created. It must continue to use the old method, right? What if the function was not inlined? for example: mat = # create SparseMatrixCSC here function calcSomething(A::SparseMatrixCSC) x = A[i,j] + 1 ... end calcSomething(mat) function getindex(A::SparseMatrixCSC, i, j) # define new getindex here end calcSomething(mat) # what happens? I understand that overriding methods in Base is playing with fire... Jared Crean - show quoted text - Yichao Yu 8/11/15 On Tue, Aug 11, 2015 at 4:42 PM, Jared Crean wrote: > Thanks for the quick reply. > > Now I am curious, what happens if the old method was inlined in a function > compiled before the new method was created. It must continue to use the old > method, right? What if the function was not inlined? > > for example: > > mat = # create SparseMatrixCSC here > function calcSomething(A::SparseMatrixCSC) > x = A[i,j] + 1 > ... > end > > calcSomething(mat) > > function getindex(A::SparseMatrixCSC, i, j) > # define new getindex here > end > > calcSomething(mat) # what happens? > > > I understand that overriding methods in Base is playing with fire... Currently basically an undefined behavior. https://github.com/julialang/julia/issues/265 - show quoted text - Tony Kelman 8/11/15 For storing explicit zeros you're best off modifying nzvals directly. In what way are you specializing your banded getindex method? Is this a classical banded but dense-within-the-band matrix, or general CSC sparse but with additional knowledge that no nonzeros ever have i and j different by more than the bandwidth? You're probably better off either making a new type for this that just wraps a SparseMatrixCSC for storage and either stores or is parameterized by the bandwidth, or using a different method other than getindex for this. If you'll miss the syntax, you could write a macro to locally replace getindex with your specialized version. - show quoted text - Jared Crean 8/11/15 Its a classical dense-within-the-band matrix (from a Finite Element problem). I want access to the solvers that are already supported by SparseMatrixCSC, and interfacing them to another new type seems like a lot of work. If there were an abstract CSC matrix type, this could be made much easier. I've been hoping issues #8001, #9906, and #9928 would lead in that direction, but so far they haven't. The syntax is really what I am after with the overriding of the methods. Using a macro is a safer alternative. I'll have to try that at some point. Jared Crean - show quoted text - Tony Kelman 8/11/15 If it's dense within the band, then what you really want is issue 8240. Are you dealing with symmetric positive definite, symmetric indefinite, or nonsymmetric? Eigenproblems or linear system solves? There are LAPACK methods for banded matrices that should be more efficient than using Cholmod or UMFPACK here, since they don't need to do anywhere near as much integer arithmetic as SuiteSparse would (to represent a band matrix in CSC format). We just don't have a Julia type for band matrices yet or ccall wrappers around the corresponding LAPACK methods. I'm not sure whether Jiahao made much progress on any prototypes, but banded matrices could easily be worked on outside of base at first. - show quoted text - Jared Crean 8/11/15 Its a nonsymmetric linear solve. Issue 8240 looks great, FE problems will be much easier to do when that is finished. I am working on a large (eventually parallel) CFD solver that will use Petsc (I'm working on wrappers here: https://github.com/JaredCrean2/PETSc.jl) for the linear solves. UMPFPACK is sufficiently efficient for debugging and running small, single processor problems. Jared Crean - show quoted text - Tony Kelman 8/11/15 For single-node work, gbtrf and gbtrs are your friends here. Apparently we do have those wrapped in base/linalg/lapack.jl already, but there are no tests for them right now, and no higher-level lufact to connect them to owing to the lack of a banded type. - show quoted text -