Paul Raynaud

The conditions for the update are fulfilled in the code above. The next piece of code use a loop which guarantee which garantees that the conditons of LSR1 are satisfied...

I have new examples of failures for `LSR1Operator` and an explanation of why they fail. ```julia lsr1 = LSR1Operator(2) y = [-5., -5.] s = [-1., -1.] push!(lsr1, s ,y)...

My SR1 implementation is very simple, it doesn't have as many numerical conditions as `push!` of LSR1Operator does. The only numerical test of my SR1 implementation is the same as...

@dpo, @tmigot, (@amontoison, @geoffroyleconte) I think this PR is pretty mature. Right now, a `CompressedLBFGSOperator` is faster to update and to perform `mul!` than the usual `LBFGSOperator`. Here are some...

> 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...

> > > And is it possible to remove CUDA from the deps? I can only see 3 lines where you use CUDA functions, maybe you could add something for...

> if you make some minor changes and document well your operator It is sure, but I think it is the user's loss. I am thinking about Requires, but not...

> 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 It would be better,...

> I don't see a big différence bewteen `T=Float64, gpu=true` and `S=CuVector{Float64}` sincerely. My code needs neither of `gpu=true` nor `S=CuVector{Float64}`; `T=Float64` being by default. If you want to switch...

@geoffroyleconte I added Requires and removed CUDA from the dependencies, and the tests pass (for the CPU. To not mess up the `__init__` of LinearOperators, I made a submodule ModCompressedLBFGSOperator...