Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Best so far swap - BestSoFarRootFinder should not be recommended to wrap LeastSquaresSolver #98

Closed

Conversation

johannahaffner
Copy link
Contributor

@johannahaffner johannahaffner commented Dec 23, 2024

This fixes a typo in the documentation. BestSoFarLeastSquares was undocumented, instead BestSoFarRootFinder was the wrapper listed in the section on least squares solvers.

I know that I used it to wrap LevenbergMarquardt, and I just checked - this will result in an unexpected solver instance.

import optimistix as optx


solver = optx.GaussNewton(rtol=1e-3, atol=1e-06)
wrapped_ls = optx.BestSoFarLeastSquares(solver)
wrapped_rf = optx.BestSoFarRootFinder(solver)

print(isinstance(wrapped_ls, optx.AbstractLeastSquaresSolver))  # True
print(isinstance(wrapped_rf, optx.AbstractRootFinder))  # True
print(isinstance(wrapped_rf, optx.AbstractLeastSquaresSolver))  # False 

In this case, it does not appear to do anything as long as optx.least_squares is used as the top-level API, because this will only check for a minimiser.

However, if optx.root_find is the top-level API and a wrapped least-squares solver is used, then the conversion to optx.least_squares won't happen, because this line will not evaluate to True:

elif isinstance(solver, AbstractLeastSquaresSolver):

@johannahaffner johannahaffner changed the base branch from main to dev December 23, 2024 11:03
@johannahaffner
Copy link
Contributor Author

I'll rebase on dev later, sorry for the oversight!

@patrick-kidger patrick-kidger changed the base branch from dev to main December 23, 2024 11:21
@patrick-kidger
Copy link
Owner

LGTM!

For this one you can merge straight to main.

The reason for a dev branch is that any changes to the docs on main are automatically reflected in the online documentation: so if we introduce a new feature then it should be on a dev branch to be sure that it is not advertised until it is released.

However conversely, doc fixes can/should go straight to main as there is no reason to delay fixing typos!

(So I think I'm still seeing the verbose changes on this branch. If you can make this branch have just the commit with the fix then I'll merge it immediately :) )

@johannahaffner
Copy link
Contributor Author

(So I think I'm still seeing the verbose changes on this branch. If you can make this branch have just the commit with the fix then I'll merge it immediately :) )

That is why I rebased on dev. I'll figure out how to make my main forget it has the verbose changes :)

However conversely, doc fixes can/should go straight to main as there is no reason to delay fixing typos!

Makes sense!

@johannahaffner
Copy link
Contributor Author

I also removed three lines in optx.root_find that seemed to be holdovers and occurred after a return statement in the elif branch.

@patrick-kidger patrick-kidger mentioned this pull request Dec 23, 2024
@patrick-kidger
Copy link
Owner

Ah, good catch! Actually, those three lines should be there and it's the return statement that's wrong. I've just opened #99 to correct this. (And I've included your BestSoFarLeastSquares fix whilst I'm at it!)

@johannahaffner
Copy link
Contributor Author

Ah, I did not catch this! Good that you did :) I'll close this PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants