Sebastian Stock

The bug is present in versions 1.1 to 1.6. It works correctly on 1.0 and master.

The first two examples (`f(I, A) = Base.literal_pow(^, I/A, Val(2//3))` and `f() = u"A/K^(3//2)"`) are now inferred correctly (in Julia 1.8). The case `g() = u"A^(3/2)"` (using a `Float64` instead...

I don’t think these units exist right now in any of the unit packages. I’m not sure whether they should be included here or live in a package of their...

Since this would be breaking, it is something to consider for Unitful 2.0. That said, I’m not sure it is worth the breaking change and I worry that `h` and...

One consequence of the intransitive `isequal` is that a correct `hash` implementation for `Gain` is impossible: We have * `isequal(Gain{Decibel, :p}(20), Gain{Decibel,:rp}(20))`, * `isequal(Gain{Decibel, :p}(20), 100)`, and * `isequal(Gain{Decibel,:rp}(20), 10)`,...

> > However, floating-point quantities might break this, since `isequal` does not necessarily convert its arguments to `upreferred` (it uses `promote`, which only falls back to `upreferred` for `FreeUnits`). I...

> I can think of two possible solutions to this: > * Change `isequal` to always convert to `upreferred`. > * Use `TwicePrecision` (is it sufficient?). Changing `isequal` to always...

Just to clarify, which of the following is the issue here: * that Unitful.jl returns plain numbers whenever the result of an operation would be a quantity with units `NoUnits`...

I’m not sure I like this, since it is not invariant under unit conversion: ```julia julia> x = 2.5u"inch" 2.5 inch julia> y = uconvert(u"cm", x) 6.35 cm julia> x...

It’s a goal of this package that all functionality is unit-invariant. That’s why `round` takes a unit argument in the first place. For `x == y`, you will always have...