Closed giordano closed 8 years ago
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 https://github.com/ajkeller34/Unitful.jl/issues/9 for all of that discussion. I am curious to read the comment thread you linked to.
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: https://github.com/Keno/SIUnits.jl/issues/83 (but without follow-up, so far). What about a specific real-only type?
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.
I think the only useful subtype of Real
that this package could support is Real
: Complex
is made up of two Real
s 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!
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 ofAbstractFloat
and takesAbstractFloat
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: https://github.com/giordano/Measurements.jl/issues/1The main thing that
Unitful.jl
should do in order to became compatible withMeasurements.jl
is to makeDimensionedQuantity
subtype ofAbstractFloat
.I understand the change I'm proposing is breaking, but it would be really cool to see error propagation for numbers with their units!