Relaxing `::Real` requirement?

[MilesCranmer]

Hi everyone,

Awesome package and ecosystem. I'm really enjoying it!

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 TuringLang 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).

Cheers,
Miles

[torfjelde]

I was wondering if the requirement for numeric types to be ::Real could be relaxed to ::Any?

Do you mean allow distributions on the RHS of ~ to use non-reals?

[MilesCranmer]

It all depends on what you mean by "real" here... For example:

using Unitful

x = 0.5u"km/h"

this is a real-valued number. However, in Julia it's actually <:Number and not <:Real, because AbstractQuantity <: Number, even though the base type of Float64 <: Real... (Meaning you can't do inference on physical quantities with Turing)

[torfjelde]

So I meant Real, the abstract type:) Because you can use whatever types you want inside a Turing.jl model, i.e. you can do inference on the raw number one line, convert it into a unit on the next, and then do all your calculations using the unitful type. But what you currently can't do is to put, say, a unitful number on the LHS of a ~. Buuut this is mainly because Distributions.jl does not support this.

[MilesCranmer]

I see, thanks.

Okay I'm currently working on this in DynamicQuantities.jl (alternative to Unitful) – JuliaPhysics/DynamicQuantities.jl#85. Once that is done hopefully you could use RealQuantity (which would be the new default for units/constants) as input to a Turing model.

[MilesCranmer]

Too bad, it seems like a lot of things in Distributions.jl are hard-coded to Float64 (or assumptions related to floats), so this is probably impossible. Thanks anyways.

[torfjelde]

Technically it's possible to support non-Distributions.jl types, but it will take time to get there and we haven't seen sufficient amount of motivation to motivation for us to prioritize it, I think 😕

But you can do stuff like:

@model function demo()
    x_without_unit ~ Normal()
    x = # make it unitful ...
end

of course.