You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was wondering if the requirement for numeric types to be ::Real could be relaxed to ::Any? Since Julia doesn't have multiple inheritance, this limits the range of types you can use perhaps more than necessary. There are some types which act exactly like a Real in every other way, except they do not inherit from Real, so it would be great if one could use those as well.
My specific use-case is I'm trying to use physical units in a Distributions model, but both Unitful.Quantity and DynamicQuantities.Quantity are <:Number so are incompatible, despite the numerical type being a Real in both cases (base type Float64).
julia>using DynamicQuantities # or Unitful
julia>Normal(10u"km/s", 1u"km/s")
ERROR: MethodError: no method matching Normal(::Quantity{Float64, Dimensions{…}}, ::Quantity{Float64, Dimensions{…}})
Stacktrace:
[1] top-level scope
@ REPL[6]:1
Some type information was truncated. Use `show(err)` to see complete types.
I think that 10 km/s ± 1 km/s is a standard description for a physical measurement so this would be useful to have.
Hi,
I was wondering if the requirement for numeric types to be
::Real
could be relaxed to::Any
? Since Julia doesn't have multiple inheritance, this limits the range of types you can use perhaps more than necessary. There are some types which act exactly like aReal
in every other way, except they do not inherit fromReal
, so it would be great if one could use those as well.My specific use-case is I'm trying to use physical units in a Distributions model, but both
Unitful.Quantity
andDynamicQuantities.Quantity
are<:Number
so are incompatible, despite the numerical type being aReal
in both cases (base typeFloat64
).I think that
10 km/s ± 1 km/s
is a standard description for a physical measurement so this would be useful to have.Cheers,
Miles
(copied from TuringLang/Turing.jl#2133 as the same issue arises there)
The text was updated successfully, but these errors were encountered: