Migrate away from Dierckx.jl

[icweaver]

Addressing the AD concern brought up by Miles

AFAICT, Interpolations.jl still doesn't seem to have ootb support for cubic B-splines on irregular grids just yet

BSplineKit.jl seems like a very nice drop-in replacement though. The output differs slightly from Dierckx.jl, but still seems to be within our test tolerances. Might just be a boundary condition thing I'm doing wrong, but still need to explore more

DataInterpolations.jl could also be the way to go. Do folks have other thoughts?

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.62%. Comparing base (af42144) to head (29f3053).

Additional details and impacted files

@@            Coverage Diff             @@
##           master      #54      +/-   ##
==========================================
- Coverage   99.62%   99.62%   -0.01%     
==========================================
  Files          10       10              
  Lines         270      268       -2     
==========================================
- Hits          269      267       -2     
  Misses          1        1              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[cgarling]

I've used DataInterpolations.jl when I had some data that their specialty interpolators were useful for. I don't really like how their syntax to construct an interpolator is interpolator(y, x) rather than (x, y) but that's a minor complaint. I have no experience with BSplineKit.jl but if it covers our needs (which seem relatively minor) I'm happy to use it.

Should this be wrapped into the 0.11.2 release? We updated the Project.toml in #50 but we can wait to register until after merging this if you want.

[cgarling]

With the caveat that I'm not familiar with this code, it seems to me it is inefficient to re-read the data for every call to f19_invum.

Why don't we load it as a constant (something like const f19_data) at the module level? I guess that would force download the datadep when you load the package but that sounds fine to me. That would also allow it's type to be known.

Frankly the data file's not even that large so we could just copy-paste the raw data into the source file unless there's some licensing issue or something ...

[icweaver]

100% agree. I was very tempted to just inline it while writing out that TODO. Will play around with some schemes later tn

[icweaver]

I've used DataInterpolations.jl when I had some data that their specialty interpolators were useful for. I don't really like how their syntax to construct an interpolator is interpolator(y, x) rather than (x, y) but that's a minor complaint. I have no experience with BSplineKit.jl but if it covers our needs (which seem relatively minor) I'm happy to use it.

Awesome, thanks for the real world feedback! I'll try it out tn

Should this be wrapped into the 0.11.2 release? We updated the Project.toml in #50 but we can wait to register until after merging this if you want.

Sure, thanks! This is shaping up to be a real nice release

[icweaver]

Ok, so I went ahead pasted that F19 dataset directly in to keep this PR from being held up. It looks like Ian from the past put current me in this corner #32 (comment). I wonder if artifacts might be what's needed to track and work with datasets internally like this?

I also tried out DataInterpolations.jl and liked it a lot! The one and only test that it seems to fail on is this one with Measurements.jl:

DustExtinction.jl/test/color_laws.jl

Lines 339 to 343 in af42144

	# uncertainties
	noise = rand(length(wave)) .* 0.01
	wave_unc = wave .± noise
	reddening = map(w -> @uncertain(law(w)), wave_unc)
	@test Measurements.value.(reddening) ≈ ref_values[rv] rtol = 1e-3

F04: Test Failed at /home/mango/projects/DustExtinction.jl/test/color_laws.jl:343
  Expression: ≈(Measurements.value.(reddening), ref_values[rv], rtol = 0.001)
   Evaluated: [0.06347334097148892, 0.24927400409113415, 0.8672265293564794, 0.9853541153619346, 1.2275044405360622, 1.3918100306783647, 2.0826715828272953, 2.1872727768019695] ≈ [0.05967741935483871, 0.24903225806451612, 0.8670967741935485, 0.9854838709677419, 1.2274193548387098, 1.3919354838709679, 2.0825806451612903, 2.1874193548387093] (rtol=0.001)

Stacktrace:
 [1] macro expansion
   @ ~/.julia/juliaup/julia-1.10.8+0.x64.linux.gnu/share/julia/stdlib/v1.10/Test/src/Test.jl:672 [inlined]
 [2] macro expansion
   @ ~/projects/DustExtinction.jl/test/color_laws.jl:343 [inlined]
 [3] macro expansion
   @ ~/.julia/juliaup/julia-1.10.8+0.x64.linux.gnu/share/julia/stdlib/v1.10/Test/src/Test.jl:1577 [inlined]
 [4] top-level scope
   @ ~/projects/DustExtinction.jl/test/color_laws.jl:319

I'm probably just holding it wrong. At any rate, I think this should be ready for review now

[giordano]

I wonder if artifacts might be what's needed to track and work with datasets internally like this?

I haven't checked what's the format of the data you're dealing with, but a note about Artifacts is that it supports only tarballs, if you don't have a tarball to start with you'd need to repackage it and upload it somewhere, which isn't always a nice thing to do (but ArtifactsUtils.jl makes this stuff easier)

[cgarling]

It's just a small matrix with a few kb of data (something like 4 columns, 100 rows). Since the data are so small I prefer this solution, and +1 for keeping the link to the raw data file in a comment so we know where it came from.

lgtm