Migrate to SciML and extend?

[ChrisRackauckas]

We're doing a lot in SciML towards a new curve fit interface, but I think this package has good bones. We're really focused on the nonlinear fitting aspect, and I think it would be a shame to have the more robust nonlinear parts separated from the nice linear fitting interface you have here. Would you be interested in migrating this over to SciML and letting us continue https://github.com/SciML/NonlinearSolve.jl/pull/339 as part of the nonlinear part here? We are looking to do a lot around the confidence intervals and that part, using the newest tooling in NonlinearSolve.jl under the hood.

[ChrisRackauckas]

Bump. @ararslan are you the maintainer now? It doesn't look like this has had any commits in over two years other than a CI bump?

[pjabardo]

I initially wrote the package for simple day to day use in my work . I was thinking about overhauling the package. What would migrating to SciML entail? If this is good for the community I would gladly do this.

[ChrisRackauckas]

Can keep you on as admin. I think there's a few things that come to mind:

• One is just helping with the general health and maintenance. Your compathelper doesn't actually run becuase https://github.com/pjabardo/CurveFit.jl/blob/master/.github/workflows/compat.yml#L11 it's not looking at the right version, the checkout action is old and doesn't cache https://github.com/pjabardo/CurveFit.jl/blob/master/.github/workflows/ci.yml#L25, you don't have a downgrade CI testing if Polynomials v1 is still viable, https://github.com/pjabardo/CurveFit.jl/blob/master/Project.toml#L11. All of that kind of maintenance stuff we have a crew and bunch of scripts for to keep things up to date.
• As mentioned in the OP, I think the API on the linear least squares part is good and would probably be kept fully intact.
• The nonlinear least squares we'd want to swap in the new bits from NonlinearSolve.jl as demonstrated in https://github.com/SciML/NonlinearSolve.jl/pull/339. In particular, this would bring in trust region and line search methods that greatly improve the robustness of convergence, which IMO should be a major factor in the high level API.
• We would then want to get this all setup in the SciMLBenchmarks (https://github.com/SciML/SciMLBenchmarks.jl) and have the machines start to auto-track not just performance but correctness and robustness across a set of algorithms. Our goal here is to get clear benchmarks against SciPy and Cares and track that over time.
• And finally, we'd want to add the statistical elements to the nonlinear API. While LsqFit.jl does not do well numerically (it tends to fail to find a good fit), it and SciPy not only give a fit but also margin of error and confidence interval estimates. Our dream here is to have all of the linear fitting tooling, plus a general nonlinear fitting tool which is highly reliable and has these confidence interval pieces, all in a single package with a uniform API and a lot of tutorials/training videos/etc. around it.

But finally, I think in general the highest level API should be as much of a "just work" interface as possible, and then people can manually set things up with the solvers if they want to tweak things around. The current situation is that both LsqFit.jl is the most widely used and it fails on almost every problem it tries on (see the Discourse threads and the DataInterpolations.jl tests on that) and it's just not a good look for Julia. So we wanted to get something with trust region line search methods out there, get a bunch of benchmarks, blog posts, JuliaCon talks on it etc., and really make a new package front and center for curve fitting. During that discussion I found this package and not only did it have a good name but it also had a good API, but was just missing the guts for the nonlinear part and all of the docs/blog posts/tutorials/workshops/benchmarks to make it a standard. Rather than trying to make a "RobustCurveFit.jl" or something that branches off from these bones, we thought it would be best to start by seeing if we could collaborate using your foundation.

@avik-pal anything to add?

[drayer587]

Gonna bump this to chime in that I would love to see a simple curve fit interface to supplant my use of LsqFit.jl. The syntax there is great, but dealing (frequently) with failed fits is not.

[ChrisRackauckas]

Friendly bump to revive the conversation

[ararslan]

@ararslan are you the maintainer now?

I am not, though I can see why one might think I am based on my extremely impressive commit history

[heltonmc]

I'm going to bump this as well. I've also found LsqFit.jl to be inaccurate and have mostly moved to setting up general nonlinear least squares problems using NonlinearSolve.jl. I think it's pretty crucial to have nonlinear curve fitting (Levenberg-Marquardt) available. Or just some function like curve_fit(f, xdata, ydata, p0, sigma, bounds, jacobian). Maybe also support ydata being a matrix as well with the accompanying f matrix output from xdata for multi-observational data.

@ChrisRackauckas It sounds like your team has done a lot of work towards this. It would be nice to be able to use and give feedback. I personally don't care if there is an LsqFit.jl, CurveFit.jl and CurveFitting.jl package. Or if this is just some functionality within NonlinearSolve.jl.

I'll try to revive some conversations here as it would be nice to have this all under the SciML org.

[ChrisRackauckas]

We can fork this library to CurveFitting.jl if there's not a response. Might as well wait for @avik-pal to have a second after his summer internship since he has the code for this already.

[JamesWrigley]

Any reason to not overhaul LsqFit.jl instead, since that's the more well-known package? In any case, I'd be willing to contribute to this effort if I can.

[avik-pal]

Any reason to not overhaul LsqFit.jl instead, since that's the more well-known package?

LsqFit.jl and Optim.jl are maintained under the same org. It might be a bit rude to replace Optim with NonlinearSolve there :sweat_smile:

[JamesWrigley]

Ah, right that's fair :sweat_smile: