Pierre-Luc Bacon

Is this partly covered by #26 and #30 ? Can we close this issue?

There might be a conceptual issue with the introduction of the "solvers" argument in #26. https://github.com/gehring/fax/blob/9701c79b64830dbc3c8b250a77394dfdc8ab6bca/fax/implicit/twophase.py#L134-L152 It looks like the only role played by potential custom "backward" is to solve...

From the perspective of Christianson and the view where `two_phase_solve` is a FP thing only, then yes I think that imposing that the backward solver operates on the backward FP...

Is this addressed in #30 ? Can it be closed?

I tend to put the FP and root finding perspective in the same basket. I think the only difference is that our interface defaults to successive approximation if no forward...

We can perhaps provide a decorator. Instead of having to write: ``` def sqrt_zero(a): def _sqrt_zero(x): return x + (a - x**2) return _sqrt_zero ``` Provide a decorator `zero_problem` that...

Here's more complete example: ``` import jax.numpy as jnp from fax import implicit def root_finding(param_func): def _fp_param_func(params): fn_op = param_func(params) def _fp_operator(x): return x + fn_op(x) return _fp_operator return _fp_param_func...

You make a good point regarding the use of successive approximation as a default "forward" solver, and how this is ill-suited and confusing for the user under the root-finding perspective....

It would be good to refactor out `default_solver` https://github.com/gehring/fax/blob/be058d17fb7d650ba1ebc093179a0f735a738054/fax/implicit/twophase.py#L13-L48 in this case. Also, this piece of code can be used in other contexts where we need to solve for lin....

*what I meant was more the part about the solver derived from the Neumann series perspective. https://github.com/gehring/fax/blob/be058d17fb7d650ba1ebc093179a0f735a738054/fax/implicit/twophase.py#L112-L120