[SPECULATIVE] Replacing Unitful.jl with DQ.jl system-wide

[icweaver]

Just jotting some disorganized notes here as I start to feel things out

Requirements

Want the following parity with Unitful.jl:

• log unit support (e.g., dB, mag, Vmag)
  • These remaining open logarithmic issues in Unitful.jl make me wonder if a simpler approach in DQ might solve a good portion
• plotting support
  • Experimental support in Makie.jl
  • Further improvements in the works: Improve dim converts recipe compatibility, usability MakieOrg/Makie.jl#5323
  • Coordinate transformations, see SkyImages.jl. Would also want in AstroImages.jl
• Unit equivalence
  • Do we want something like UnitfulEquivalences.jl?
  • See Chris' comment about spectral density support: Explore moving out units and/or plotting SpectrumBase.jl#31 (comment)

Timeline

• Not any time soon. Will be looking to SciML's developments in their Unitful --> DQ transition
• Package extensions may be a good way to start experimenting with this

Extension experiments

• Cosmology.jl: [EXPERIMENTAL] Use DynamicQuantities.jl as default units backend Cosmology.jl#62
• DustExtinction.jl
• Spectra.jl

[cgarling]

Hey Ian, some quick thoughts:

It would be nice to have a short description of what this switch would do for us. I have not really used DQ.jl as I have never come across a situation where Unitful.jl did not work for my use case. A short description of what DQ can do that Unitful cannot would be nice to motivate these changes (what problem does this solve?).

From my perspective as both a developer and a user, the most important considerations are ease of development/maintenance and interop between packages I imagine developing for both Unitful and DQ might involve some additional work on the behalf of developers over our previous stance of just using Unitful. And the stance of "just use Unitful" makes it easy to take output from one of packages and feed it into another.

My understanding is that conversion from Unitful types to DQ types is extremely cheap (e.g., convert(DQ.Quantity, 1*Unitful.s)), so if someone wants to use DQ in some downstream analysis, it is straightforward to convert to the DQ types given our output in Unitful types.

Presently I have a preference for Unitful as I occasionally need to dispatch on the dimensions of a quantity which I understand you can't easily do with DQ because the dimensions are not part of the type signatures.

[icweaver]

Thanks, Chris! More updates coming soon. I'll try to address your current questions broadly:

I agree with you on all points for the current and near-term. To be clear, this issue is more for the long term as I and other folks start to fill in DQ.jl more for the cases that we might need.

In no particular order, these are a few motivating factors for me to at least start to explore this more. I'll be filling this out in the top-level comment more as time goes on:

• Simpler type signatures for easier debugging and approachability for new users
• (To explore) Maintain 1st class compatibility with SciML. They appear to be transitioning to DQ, with major buy-in from Chris R. Most recently, it looks like ModelingToolkit.jl has adopted DQ as their default units backend since v9. Update: more reasoning here
• Units and constants are unified. No separate PhysicalConstants.jl + Unitful.jl + UnitfulAstro.jl trio required anymore that relies on "spooky action at a distance", as noted by DQ developer. I still need to internalize this point more.
• (To explore) Working in a single unit system internally (SI) may simplify future package dev. I'm beginning to explore more how much the internal ustripping in the PhotometricFilters.jl examples you shared exactly buys us.
• I like how they handle arrays, i.e., attaching the unit to the array instead of having an array of units. Besides the performance benefits shown in the docs, I also like how it naturally lends itself to plotting. I think this correspondence will be even nicer once axis unit label support is in in this Makie PR

So tl;dr, I agree with you for the current time frame, but want to explore if this will still be the case for the longer-term

[icweaver]

Presently I have a preference for Unitful as I occasionally need to dispatch on the dimensions of a quantity which I understand you can't easily do with DQ because the dimensions are not part of the type signatures.

I'm not sure I would treat this as a blocker if we can get a simple PR in. For example, (just lifting this from their display system):

julia> using DynamicQuantities

julia> function dims(q::Quantity) # Or whatever
           d = dimension(q)
           filter(k -> !iszero(d[k]), keys(d))
       end
dims (generic function with 1 method)

julia> islength(q::Quantity) = dims(q) == (:length,)
islength (generic function with 1 method)

julia> isspeed(q::Quantity) = dims(q) == (:length, :time,) # etc.
isspeed (generic function with 1 method)

julia> islength(3u"m")
true

julia> isspeed(3u"m/s")
true

This is one of the things I would like to explore more, so thanks for bringing this back up! Maybe this could even be made as a trait, will follow up with Miles!

[cgarling]

Thanks Ian! Those reasons make sense.

Checker functions like these are good, though I think you have to check the values of the dimension(q) too right? To make sure it's 1 for the length case, for example

julia> function islength(q::Quantity)
    d = dimension(q)
    dd = filter(k -> !iszero(d[k]), keys(d))
    return dd == (:length,) && d.length == 1
end

They also aren't free since you have to do the actual value checks

julia> t=3u"m"
3.0 m

julia> @benchmark islength($t)
BenchmarkTools.Trial: 10000 samples with 999 evaluations per sample.
 Range (min … max):   9.296 ns … 45.587 ns  ┊ GC (min … max): 0.00% … 0.00%
 Time  (median):     11.058 ns              ┊ GC (median):    0.00%
 Time  (mean ± σ):   11.152 ns ±  1.131 ns  ┊ GC (mean ± σ):  0.00% ± 0.00%

          ▂     ▂▁ ▇ ▃ █ ▁
  ▂▂▂▂▃▃▄▃█▄▆▃█▅██▇█▅█▅█▆█▅▇▆▆█▄▇▅▅▃▃▂▂▂▂▂▂▂▁▂▂▂▂▂▂▂▂▂▁▂▂▁▁▂▂ ▃
  9.3 ns          Histogram: frequency by time        14.6 ns <

 Memory estimate: 0 bytes, allocs estimate: 0.

[giordano]

Yeah, the main design difference of DynamicQuantities vs Unitful is that the former needs to do runtime checks all the time, the latter can do dimensionality checks at compile time. Of course compile time checks are cool in principle, but come at the cost of added latency. There's always trade-offs either way.

[icweaver]

I think you have to check the values of the dimension(q) too right?

Good point, thanks! Sounds like a nice way to handle volumes and areas and such too

There's always trade-offs either way.

Yea, my speculative thinking at this point is that the large majority of cases where we care about nice unit handling in JuliaAstro will be at the user-facing boundaries, like plotting and simple calculations, where performance is already limited by other factors. I could be totally wrong though, which is why I want to try things out in these experiments