Giters

JuliaNLSolvers / NLsolve.jl

Julia solvers for systems of nonlinear equations and mixed complementarity problems

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Support Anderson Acceleration for fixedpoint

jlperla opened this issue · comments

commented

Right now the :anderson is implemented as a solution for solving nonlinear problems. (where the solver turns the system into a fixed point problem.

Following something similar to #151 we could use the existing solver code by a small modification.

However, in the long-run it would make sense to rewrite (or copy) the Anderson code for direct fixed point problems to help its speed, as the above method would be taking a fixed point problem, converting it to a nonlinear system, and then converting it back to a fixed point problem in the underlying Anderson implementation.

commented

However, in the long-run it would make sense to rewrite (or copy) the Anderson code for direct fixed point problems to help its speed

How would it help its speed? What part of the algorithm would be changed?

commented

The tight inner loop in https://github.com/JuliaNLSolvers/NLsolve.jl/blob/master/src/solvers/anderson.jl would be a little different. Longrun it is worth seeing it it matters. Longrun.

commented

What would change in there?

commented

I'm not sure what you mean by this. Do you mean that there is the potential of inefficiencies because the code basically does x + (g(x) - x)? Sure. Anderson makes much more costly computations in its algorithm (and there are much bigger problems in the implementation, cf #128), so I'd be extremely surprised if that mattered, though. In any case I don't think it's worth complexifying the API/code.

commented

Yes, that is what I meant. I said longrun for a reason, I just didn't want to forget about it.

Looking at but very low priority, but this is the sort of algorithm to squeeze every imaginable efficiency out of (since it is often near the center of a whole bunch of type iterative procedures in economics algorithms).

Not worth spilling ink over, I just made a comment to point out that benchmarking would be worth looking at to see if it eliminates overhead in the implementation compared to embedded code.

commented

I would be very surprised if the difference it makes is greater than 0.1%