Compatibility with Measurements.jl

[giordano]

Let me first express my appreciation for the package, looks really nice! I like very much the possibility to have units with rational exponents, maybe not really physical but useful in calculations. In addition, it appears to be much faster than SIUnits.jl, yet it has more features (for what I can see).

I'd like to ask you whether it is possible to make this package compatible with Measurements.jl, a library for uncertainty propagation. This package provides a new type, Measurement, which is subtype of AbstractFloat and takes AbstractFloat numbers with uncertainty, then instructs most mathematical operations to correctly propagate the uncertainty to the result. You can read here the discussion which led to the final choice: JuliaPhysics/Measurements.jl#1

The main thing that Unitful.jl should do in order to became compatible with Measurements.jl is to make DimensionedQuantity subtype of AbstractFloat.

I understand the change I'm proposing is breaking, but it would be really cool to see error propagation for numbers with their units!

[ajkeller34]

Thanks for the kind words! Rational exponents can be very useful indeed, typically voltage noise is measured in V/Hz^(1/2).

Fortunately, I think Unitful works with Measurements already, provided you organize the terms appropriately:

julia> using Unitful

julia> using Measurements
INFO: Recompiling stale cache file /Users/ajkeller/.julia/lib/v0.5/Measurements.ji for module Measurements.

julia> (1±0.1)u"μm"
1.0 ± 0.1 μm

julia> ans + (2±0.1)u"cm"
0.020001 ± 0.001000000005 m

julia> ans * 2
0.040002 ± 0.00200000001 m

julia> ans * (2±1)
0.080004 ± 0.04020149256134653 m

This works because Quantity is wrapping Measurement, rather than the other way around. Also, I had quite a long discussion with Tim Holy and we came to the conclusion that Quantity should subtype Number, but not anything more specific. See #9 for all of that discussion. I am curious to read the comment thread you linked to.

[giordano]

Wow, it was so obvious, but I didn't think about wrapping Measurement in Quantity! That's probably a bias of mine, being the author of the other package ;-). I'm closing this ticket.

I'll probably describe the combination Unitful.jl + Measurements.jl in the documentation, I believe this can be very handy for users! And it's amazing how Julia lets you easily combine different types.

Regarding the subtyping of Quantity, I see that technically it's useful to have it subtype of Number, but there are many functions that really require Real (or sometimes more specific) arguments, and being physical quantities usually real-only they often fall in this case. This was reported by Steven Johnson to SIUnits.jl here: Keno/SIUnits.jl#83 (but without follow-up, so far). What about a specific real-only type?

[ajkeller34]

I think the crux of the problem is that nowhere in the documentation or the source of Julia, to my knowledge, is a definition of how a type subtyping Real is allowed to behave. Therefore, people may be using this abstract type inconsistently, depending on what property of real numbers they are thinking about. The only safe way to behave in this environment is to be very strict about what can be Real. Most would agree that you can add two real numbers. You can't add a meter and a gram, however, so should we be calling them Real?

I initially tried making a whole slew of Quantity types for each other abstract subtype of Number, but it was a lot of work and made for very ugly code. I think it turned out much cleaner in the end, even if I had to reimplement a few functions that I would have inherited for free from Real. In fact, I think the greatest takeaway from my whole exercise in writing Unitful was that its much better to avoid being overly specific with the types, and just reimplement methods where needed.

[giordano]

I think the only useful subtype of Real that this package could support is Real: Complex is made up of two Reals and in Julia standard library many functions of complex arguments internally split the real and imaginary parts and do calculations with them, as Steven Johnson pointed out in the discussion I linked above. In this way the whole Number abstract type is covered.

However I understand that implementing yet another specific type within the package may lead to ugly code.

PS: I documented the use of Measurements.jl with SIUnits.jl and Unitful.jl: http://measurementsjl.readthedocs.io/en/latest/examples.html#use-with-siunits-jl-and-unitful-jl Please tell me if you have other suggestions!