Skip to content

Scalarize input#202

Open
gustaphe wants to merge 5 commits intoJuliaNLSolvers:masterfrom
gustaphe:scalar
Open

Scalarize input#202
gustaphe wants to merge 5 commits intoJuliaNLSolvers:masterfrom
gustaphe:scalar

Conversation

@gustaphe
Copy link

@gustaphe gustaphe commented Oct 25, 2021

This is a breaking change, but one that I really feel makes LsqFit more Julian. Would close #145

Instead of

model(x, p) = exp.( - ( x .- p[1] ).^2 ./ p[2]^2 )

the model definition (the operation which involves the user the most) becomes

model(x, p) = exp( - ( x - p[1] )^2 / p[2]^2 )

i.e. the user doesn't need to think about the shape of x, they just define the behavior with respect to a scalar.

From the tests, it looks like you are just moving the complexity from the model definition to the data generation
(which goes from y = model(x, p) to y = model.(x, Ref(p))), but note that in real world cases you wouldn't be generating the data from your own model like this.

One part that I'm a bit uncertain about is multivariate models: I've currently written it so that the x argument for curve_fit is a AbstractArray{AbstractArray} (e.g. [ [1.0, 3.0], [2.0, 3.4], [1.5, 2.0] ] for a two-variable function with three datapoints). One might want to go through and change this to accept matrices, I just haven't (yet). There are afaict currently no tests for multivariate fitting either.

Oh, and the tests weren't passing (some of them even crashed) before, so I relaxed them a bit in the first commit.

Are you interested?

@pkofod
Copy link
Member

pkofod commented Oct 31, 2021

Yes. You are right that it's a breaking change, so it would have to be postponed a bit, but I think it's a better interface.

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.

Allow passing in a scalar function instead of a vector function

2 participants