# UnitfulLsqFit

**URL:** <https://discourse.julialang.org/t/unitfullsqfit/57815>\
**Category:** Package Announcements\
**Tags:** unitful\
**Created:** [March 23, 2021, 6:51pm UTC](https://discourse.julialang.org/t/unitfullsqfit/57815 "2021-03-23T18:51:51Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![gustaphe](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gustaphe/32/18174_2.png) [@gustaphe](https://discourse.julialang.org/u/gustaphe)\
**Post date:** [March 23, 2021, 6:51pm UTC](https://discourse.julialang.org/t/unitfullsqfit/57815/1 "2021-03-23T18:51:51Z")

</div>

This is not registered, in part because I think there are features in LsqFit.jl that I haven’t implemented an interface to yet, and in part because I wanted to know if anyone else wants this before I polish it further than I need for my personal use.

# UnitfulLsqFit

Has _this_ ever happened to _you_? You’re doing some physics in Julia, and enjoying the fact that you don’t have to keep track of your own units with `Unitful.jl`. You plot your velocities against your times (simple, thanks to `UnitfulRecipes.jl`) and notice a pattern that you wish to explore numerically. So you fire up `LsqFit.jl` and ask it to fit a curve. Chaos ensues:

```julia
ERROR: MethodError...

```

> oh great, now I have to convert my pretty unitful vectors to float ditto

```julia
julia> t_stripped = t / u"s" # this should do it. Or is there a reason I should be using `ustrip`? Panik...

```

…

> Okay, now I have my fit, but what do these parameters mean? I better convert back to those units I removed before. This should be possible to automate…

Well it happened to me. Here’s my latest addition to the Unitful toolbox: `UnitfulLsqFit.jl`! It extends the `curve_fit` function from `LsqFit.jl` to accept, and treat correctly (I think), Unitful quantities. It’s the one piece that was missing for me to go fully unitful on everything.

```julia
fit = curve_fit(model, t, v, p_0) # kalm

```

See a slightly more in-depth example in the docs.

## Docs

> **[UnitfulLsqFit · UnitfulLsqFit](https://gustaphe.github.io/UnitfulLsqFit.jl/dev/)**

## Repo

> **[GitHub - gustaphe/UnitfulLsqFit.jl](https://github.com/gustaphe/UnitfulLsqFit.jl)**
>
> Contribute to gustaphe/UnitfulLsqFit.jl development by creating an account on GitHub.

---

<div class="post-metadata">

**Author:** ![oschulz](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oschulz/32/2998_2.png) [@oschulz](https://discourse.julialang.org/u/oschulz)\
**Post date:** [March 23, 2021, 8:01pm UTC](https://discourse.julialang.org/t/unitfullsqfit/57815/2 "2021-03-23T20:01:18Z")

</div>

I wonder if it might make sense to have a lightweight “AbstractUnitful” package that only defines the abstract types related to units and functions like ustrip. That way, packages could add unit compatibility without adding the full Unitful to their deps.

So basically the same successful approach as with Recipes, Adapt and ChainRulesCore. Units are a very fundamental concept, after all.

---

<div class="post-metadata">

**Author:** ![jzr](https://avatars.discourse-cdn.com/v4/letter/j/eb9ed0/32.png) [@jzr](https://discourse.julialang.org/u/jzr)\
**Post date:** [March 23, 2021, 8:08pm UTC](https://discourse.julialang.org/t/unitfullsqfit/57815/3 "2021-03-23T20:08:25Z")

</div>

> [@oschulz](#):
>
> I wonder if it might make sense to have a lightweight “AbstractUnitful” package

> <https://github.com/PainterQubits/Unitful.jl/pull/428>
>
> This PR adresses issue #424 and issue #359.
> 
> \- I have moved all the files exce…pt "pkgdefaults.jl" and "dates.jl" into a subdirectory package UnitfulBase.
> \- I also moved the definitions of radian, steradian and degrees into UnitfulBase. The reason for that was \[the extension of the function \`mod2pi\`\](https://github.com/PainterQubits/Unitful.jl/blob/e52c19243e264f77c13fcf23d612df1cfad42f0b/src/quantities.jl#L125) which uses degrees. I have decided to move degrees into UnitfulBase instead of keeping \`mod2pi\` extension in Unitful. Since radian and steradian are dimensionless and thematically connected to degrees, I have moved them as well.
> \- Unitful is now a registered extension of UnitfulBase.
> 
> \- I have edited the tests so they work with the splitted UnitfulBase. I have run the tests on my computer: they run successfully with the exception of the single test for issue #272 (see \[these lines\](https://github.com/PainterQubits/Unitful.jl/blob/ca230d46155d9d893a62b8afec403bd146748ba9/test/runtests.jl#L1725-L1730)). The problem is that if @u\_str is imported without at least importing Unitful, Unitful is not registered as an extension of UnitfulBase.
> 
> \- Since UnitfulBase is not a registered package yet, the only way to add it to Unitful project environment was to \`dev\` it. The information about the path to UnitfulBase was stored only in Manifest.toml, which I did not commit. As a result, the tests might be broken in CI for now. If this PR will ever get merged, the problem will disappear once UnitfulBase is registered as a package.
> 
> I did not touch the docs yet. I would like to hear your opinion about the contents of this PR first.

---

<div class="post-metadata">

**Author:** ![giordano](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/giordano/32/2166_2.png) [@giordano](https://discourse.julialang.org/u/giordano)\
**Post date:** [March 23, 2021, 8:24pm UTC](https://discourse.julialang.org/t/unitfullsqfit/57815/4 "2021-03-23T20:24:43Z")

</div>

I don’t think that pull request in the current form does what Oliver suggested. It just moves most of `Unitful` to `UnitfulBase`

---

<div class="post-metadata">

**Author:** ![Guillawme](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/guillawme/32/30025_2.png) [@Guillawme](https://discourse.julialang.org/u/Guillawme)\
**Post date:** [April 19, 2021, 7:31pm UTC](https://discourse.julialang.org/t/unitfullsqfit/57815/6 "2021-04-19T19:31:56Z")

</div>

It seems to me that it still makes sense to have all seven SI base units in `Unitful.jl`, since most other units in common use are derived from them.

---

<div class="post-metadata">

**Author:** ![Guillawme](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/guillawme/32/30025_2.png) [@Guillawme](https://discourse.julialang.org/u/Guillawme)\
**Post date:** [April 19, 2021, 7:45pm UTC](https://discourse.julialang.org/t/unitfullsqfit/57815/7 "2021-04-19T19:45:01Z")

</div>

I would totally use a unit-aware `LsqFit`! It would not only be super convenient for daily work, but also wonderful for teaching: when calculating things manually, students are expected to keep track of units to present a meaningful result at the end, so why expect less of a program?

A related idea: it would be great if `curve_fit()` could also accept a vector of [`Measurements`](https://github.com/JuliaPhysics/Measurements.jl). As it is now, you have to provide a vector of X values, a vector of Y values, and optionally a vector of some kind of uncertainties on the Y values (most commonly `std` of replicate Y values); but it would be so convenient if you could give it a vector of `Y ± Z` of type `Measurement`. As things are now, if you want to, say, plot data points with error bars and also do curve fitting, you have to keep around the original vectors of Y values and their uncertainties in addition to the vector of `Measurement`, even though they are the same data, because `LsqFit` doesn’t understand `Measurement` types.

Finally, it seems like `curve_fit()` could work seamlessly with both units and uncertainties, since you can already do this and get a result that makes sense:

```julia
julia> using Unitful
julia> using Measurements
julia> x = [i * u"m" ± j * u"cm" for (i, j) in zip(1:10, 1:10)]
10-element Vector{Quantity{Measurement{Float64}, 𝐋, Unitful.FreeUnits{(m,), 𝐋, nothing}}}:
 1.0 ± 0.01 m
 2.0 ± 0.02 m
 3.0 ± 0.03 m
 4.0 ± 0.04 m
 5.0 ± 0.05 m
 6.0 ± 0.06 m
 7.0 ± 0.07 m
 8.0 ± 0.08 m
 9.0 ± 0.09 m
 10.0 ± 0.1 m

```