Open singularitti opened 10 months ago
My understanding is that Measurements is designed to work nicely with whatever package is used for units: https://juliaphysics.github.io/Measurements.jl/dev/usage/#Error-Propagation-of-Numbers-with-Units. So it ought to be possible to create a package extension to handle Unitful quantities - whether with uncertainties or not.
The easiest way would be a lightweight function, like I did for Measurements in PR #248, that removes the Quantity
wrapper and calls LsqFit again with the underlying data. If that data has uncertainties, they should then get handled correctly by the Measurements package extension. However, something I'm less sure about would be how to handle units within the fitting parameters themselves - would it be safe to simply strip the quantities from these, or is there some conversion magic that would be lost by this?
Hi @chriswaudby, I was doing it in my package: stripping units before fitting, and re-adding units to the fitted parameters.
would it be safe to simply strip the quantities from these, or is there some conversion magic that would be lost by this
My rule of thumb is: use whatever the input parameters' units are (they may be different from each other). However, consider that the units of xdata
and ydata
might differ from the parameters' units; therefore, we should consider a fitting technique that is agnostic to the units.
In the above example, model
with p0
will give results of dimension "mass," supposedly in u"kg"
. However, the ydata
could be in different units, such as u"g"
or u"lbs"
. Therefore, we should ensure that the ydata
and the values produced by the model
are in the same unit system.
This might get complicated! Perhaps what we need to do is:
ydata
and p0
ydata
and p0
model
:
ydata
curve_fit
Does this seem sensible?
What to do about weights - is it sufficient just to strip these and use numerical values (provided all weights have the same unit)?
Would you consider supporting fitting x- and y-data which has units that are defined by Unitful.jl? For example,
I'm having the following stacktrace:
The problem seems to be in this line:
Where
x
haseltype
ofQuantity{Float64}
, which cannot apply ontoNaN
. I guess this can be changed since we are only allocating an array, whereNaN
does not really matter here.Versions:
Similar: #248 #143