About two years ago, we updated the autodiff for the algebraic solver, thanks to @jgaeb. There was also some effort to give the algebraic solvers variadic arguments. It seems most of the code is there but the whole thing is still wrapped in a function with a strict signature. This is also what gets described in the function reference and what the latest version of Stan runs.
Is there a reason why we didn’t complete the variadic signature? I’m happy to finish this but I’m curious about how this slipped through the cracks.
Another thing I noted is that the Newton and Powell methods admit slightly different tuning parameters. I think this is fine, we’ll just need to document this carefully.
We actually have a design pickle to maintain backward compatibility for the two algebraic solvers currently exposed in the Stan language, algebra_solver and algebra_solver_newton. The problem is that these functions both admit tuning parameters of the solver as optional argument. So we cannot – without some substantial work – distinguish the tuning parameters from the variadic arguments that get passed to the algebraic system.
A similar scenario unfolded for the ode integrators.
The way around this is to give the solvers which admit variadic arguments a new name. Here are the proposed names:
solve_newton
solve_newton_tol
solve_powell
solve_powell_tol
The currently exposed signatures are maintained but we produce a warning message which indicates they are deprecated.
I think giving them a new name is the right way to go. Keeping the original name non-variadic will allow us to automatically translate old calls into new calls during deprecation analysis as well.
The proposed names look good and renaming is the same solution we did for the ODE solvers.
I’m not so sure it would require “substantial work” to keep the old names though.
The variadic args are checked at
and I think the only change needed here is that if optional tuning parameters are passed then args must match expected_args @ tuning_params instead of just expected_args. That should be pretty easy to distinguish.
Of course the backend needs to generate different calls at the C++ level so I guess solve and solve_tol variants should be different functions in the MIR and that’s a bit weird when if they have the same name in the frontend. I think renaming the function from algebra_solver to algebra_solver_tol during typechecking would be acceptable, though a bit hack-ish. (Note that the functions converting typed -> untyped must convert the name back…)
Indeed, I think this would be how to address it if we did not want new names. I’m not sure it is worth the extra work relative to just making a new name though, and I think it is easier for end users to glance at a program and tell which version it is using based on the name.