ExponentialUtilities v1.3

[MSeeker1340]

Two main jobs to do:

• Address Drop ishermitian and opnorm requirement for custom operator types. #8.
• Write new version of phiv! analogous to expv! with Saad.

Note that I've refactored expv into two functions, depending on the choice of mode. This is because the code for the two stopping modes are vastly different and they use different keyword arguments.

[ChrisRackauckas]

you might want to mention the DiffEqOperator helper @YingboMa made for this. We should add ishermitian and opnorm to it though.

[ChrisRackauckas]

It's confusing that both of them are called expv! with different arguments. It'll be fine if it gets appropriate documentation though.

[ChrisRackauckas]

I like the mode choice in the high level allocating version.

[jagot]

I think it looks nice!

[MSeeker1340]

Did some extensive structural changes. krylov_expv.jl is renamed to krylov_phiv_error_estimate.jl and the expv! function using Saad is renamed to expv_ee!. Furthermore, things related to stegr is separated into two parts: those independent of exponentiation (basically StegrWork) are moved to a new inner module Stegr while those used by expv!_ee are merged into krylov_phiv_error_estimate.jl.

@jagot would you like to develop Stegr into a separate package? Maybe also extend LinearAlgebra.eigen! for SymTridiagonals so that user-level code doesn't need to use stegr!?

BTW, I'd like to drop the initial plan of implementing phiv_ee! since I'm still debating about the details, and this PR already has enough changes. I'll also need to update OrdinaryDiffEq regarding the opnorm change after tagging the v1.3 release. @ChrisRackauckas for the update, should I keep backward compatibility (i.e. still allow passing in the opnorm function instead of a value) for now so that update on the OrdinaryDiffEq part is easier?

[jagot]

In fact, I do not like the change to expv_ee!, quite the contrary. As I lined out in #10, I would prefer it to not even have the cache as a separate argument. I think the operator should be tagged with the cache such that the correct algorithm is chosen via dispatch, so you only ever need to write expv!(b, t, A, x).

Regarding stegr!, I don't think it should go into a separate package, as it breaks the functionality as-is at the present. Merely implementing eigen! will not work since more cache is necessary beyond a tridiagonal matrix. I also don't think we need shun Lapack functions, just look at e.g. BandedMatrices.jl

[MSeeker1340]

In fact, I do not like the change to expv_ee!, quite the contrary. As I lined out in #10, I would prefer it to not even have the cache as a separate argument. I think the operator should be tagged with the cache such that the correct algorithm is chosen via dispatch, so you only ever need to write expv!(b, t, A, x)

Fair point.

Regarding stegr!, I don't think it should go into a separate package, as it breaks the functionality as-is at the present.

Since we're just extending stegr! with StegrWork, how is this breaking the current funtionality? The original stegr! isn't changed after all.

Merely implementing eigen! will not work since more cache is necessary beyond a tridiagonal matrix.

Sorry I'm not making things clear. What I suggest is to add

import LinearAlgebra: eigen!

function eigen!(A::SymTridiagonal{T}, sw::StegrWork) where {T <: Real}
  stegr!(A.dv, A.de, sw)
  ... # wrap things in an Eigen object
end

The intention is that, if you're a power user and want a faster eigen!, you can just allocate a StegrWork and then proceed to use eigen! pretty much the same way as before, without having to switch to stegr! in the user code.

[MSeeker1340]

Added backward compatibility for opnorm input that is a function (e.g. what is currently done by the ExpRK integrators). OrdinaryDiffEq tests pass on master.