Excuse my naivete, but I had assumed that the “Julian” approach to something like you’ve described as being to simply add type to the positional argument:
function LinearAlgebra.eigvals( A::Hamiltonian )
# content
end
function LinearAlgebra.eigvals( A::Liouvillian )
# content
end
I hadn’t even considered that it was possible to overwrite a positional argument’s “name” in a Julia method. I can accept that my desire might require a Julia 2.0, and thus will never happen, but it is slightly disappointing to me that that functionality was preferred over allowing LinearAlgebra( A=stiff_matrix ) usage. I’m sure there’s way more functionalities and capabilities that are enabled other than just this single tradeoff, but if it was simply “one or the other” then it seems more natural to follow the form common in mathematical writing:
A generalized eigenvalue problem (second sense) is the problem of finding a (nonzero) vector \mathbf {v} that obeys
\mathbf{A} \mathbf {v} = \lambda \mathbf {B} \mathbf {v} ,
where \mathbf{A} is a sparse positive-definite matrix and \mathbf{B} is a sparse diagonal matrix
\mathbf{A} might in fact be a stiffness matrix (or an assembly operator), and \mathbf{B} a mass matrix (operator), but the equation (function) isn’t fundamentally different if you wrote it \mathbf{K} \mathbf {d} = \lambda \mathbf {M} \mathbf {d}. In my worldview the information about the structure \mathbf{A} and \mathbf{B} are should be communicated in the type (i.e., where _ is a ...), not in the variable name.
All that being said, I view this more as a “nice-to-have” rather than a “blocker”, I just use comments in my code to get around readability issues when I see them:
# Solve Aϕ=λBϕ, where A = stiff_matrix, B = mass_matrix
Arpack.eigs( stiff_matrix, mass_matrix; nev=1, which=:SR, sigma=1.0)[0]