For probabilistic programming in particular, it’s critical to be able to use distribution-related functions (especially logpdf) in non-standard ways. For example, I would love to be able to call logpdf(TDist(nu),x) where nu and/or x have type ApproxFun.Fun SymPy.Sym ModelingToolkit.Operation It s…

[image] cscherrer: type constraints like logpdf(::Normal, ::Real) For that, I think we had the same discussion earlier in Type constraints in Distributions and StatsFuns .

[image] mohamed82008: For that, I think we had the same discussion earlier in Type constraints in Distributions and StatsFuns So we did, thanks for linking. Do you think having f(x::Real) call a generic, no-bounds-check, unexported _f(x) could solve both problems?

It could but I don’t think that’s a neat fix. Perhaps, someone else has a more useful opinion on this. A keyword argument can also work to remove the check.

[image] cscherrer: So we did, thanks for linking. Do you think having f(x::Real) call a generic, no-bounds-check, unexported _f(x) could solve both problems? I actually like the idea from an ease-of-use persepctive, but I wonder if someone could speak to what the performance of this would be.…

[image] cpfiffer: Does the fact that the “workhorse” function doesn’t actually have formal typing reduce performance? As I understand there’s no penalty for generic functions, as long as they’re type-stable. Code specializes each time it’s called with a different argument type.

I like the idea of a keyword argument to remove checks

Wouldn’t the body of the function still need to check the keyword, making this still a runtime check?

Indeed, we could make this the last positional argument with Val{true} and Val{false} to dispatch on

[image] cscherrer: Wouldn’t the body of the function still need to check the keyword, making this still a runtime check? Not necessarily. Constant prop on the literal will likely kick in.

[image] ChrisRackauckas: Constant prop on the literal will likely kick in. Any way to encourage this? Does inlining help? Otherwise, I like @mbesancon ’s Val types idea, but we could even make it struct Unsafe end and effectively push the check to the type level

Distributions.jl interop for probprog

Specific Domains Probabilistic Programming

mohamed82008 July 29, 2019, 12:42am 12

Ya this is addressed in the other topic I linked Type constraints in Distributions and StatsFuns.

Topic		Replies	Views
Type constraints in Distributions and StatsFuns Tooling	11	1301	April 8, 2019
Reworking Distributions.jl Statistics proposal	51	5717	April 27, 2020
Simplifying Distributions type hierarchy Statistics	14	1695	December 6, 2019
Questions about contributing to Distributions.jl Statistics question	41	2917	June 19, 2020
Distribution in 1.4.2? Statistics package	2	541	June 11, 2020

Distributions.jl interop for probprog

Related topics