geoffroyleconte

Hi, thanks for this PR. Usually in this package the functions to perform matrix-vector products are implemented in `prod!`, for example: https://github.com/JuliaSmoothOptimizers/LinearOperators.jl/blob/a2043722a09efdf64ed89a6d4912606a9c419ab9/src/lbfgs.jl#L201 Is it possible to make a similar change...

I agree with @amontoison here. Maybe you could use Requires.jl (see https://github.com/JuliaSmoothOptimizers/RipQP.jl/blob/d69c91618b95731f32cd2701f945bad1c254e3f6/src/RipQP.jl#L19) if there is no other choice, but I feel like it could be avoided if you make some...

Then I would advice not adding CUDA in the dependencies. We used the following multiple times in this package: > https://github.com/JuliaSmoothOptimizers/LinearOperators.jl/blob/a2043722a09efdf64ed89a6d4912606a9c419ab9/src/constructors.jl#L28 Using what you propose would mean changing all these...

I still think that removing CUDA entirely is a better solution. As mentionned by @amontoison you would also be able to use other GPU backends. You could add a constructor...

The LBFGS Operator in this package uses scalar indexing so it is not made for GPUs anyways. As I mentionned in a previous message, the API in this package currently...

> Sorry for the slow reply here. The obvious workaround would be for `nargs` to be an input to the constructor. Or we could have two constructors, `LinearOperator` and `LinearOperator5`...

Yes, this is probably because the parametric type `LinearOperator` has 3 of its parameters `F, Ft, Fct` that are the types of `prod!`, `tprod!`, `ctprod!`, and when using closures these...

Why is it not a good idea? https://docs.juliaplots.org/latest/gallery/pgfplotsx/generated/pgfplotsx-ref001/#pgfplotsx_ref001

Probably, the only issue would be that if there is an error because of `Tf`, it would be more difficult to debug (for example I don't know if this would...

Probably not, but the factorization would not be accurate for complex matrices. I opened https://github.com/JuliaSmoothOptimizers/LimitedLDLFactorizations.jl/pull/79. I left `lldl` with a Symmetric / Hermitian matrix with the `Real` type restriction, but...