Add StatsBase.predict to the interface

[sethaxen]

As suggested in TuringLang/DynamicPPL.jl#466 (comment), this PR adds StatsBase.predict to the API with a default implementation.

[sethaxen]

Bump, maybe @devmotion or @torfjelde?

[sethaxen]

Bump again.

[torfjelde]

Cheers for the bump; had missed this!

It's worth noting that DPPL is still not compatible wtih [email protected] so we might also want to add this to [email protected].

Furthermore, I'm slightly worried about the state of AbstractPPL atm; it's not clear if anyone has any ownership of the package atm, and IMO it's objectives are a bit all over the place.
I'd personally be happy to go against what was originally suggested in TuringLang/DynamicPPL.jl#466 (comment) and just putting this directly in DPPL.

Or we need to start giving AbstractPPL some love 😕

[yebai]

@sunxd3 can help backport this to v0.5 once merged.

It would be great to update DynamicPPL to support [email protected] thought.

[sunxd3]

I can try and help bring DynamicPPL up to AbstractPPL 0.6, what exactly break in 0.6 from 0.5 @yebai @torfjelde ?

[yebai]

@sunxd3 It is related to changing behavior of the colon syntax. You can follow this issue TuringLang/DynamicPPL.jl#440 and the issues it linked.

We can discuss this more in our next meeting.

[codecov]

Codecov Report

Attention: 8 lines in your changes are missing coverage. Please review.

Comparison is base (b342b3d) 84.82% compared to head (7862931) 80.39%.
Report is 5 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #81      +/-   ##
==========================================
- Coverage   84.82%   80.39%   -4.44%     
==========================================
  Files           3        3              
  Lines         145      153       +8     
==========================================
  Hits          123      123              
- Misses         22       30       +8     

Files	Coverage Δ
src/abstractprobprog.jl	40.00% <0.00%> (-45.72%)	⬇️

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[yebai]

@torfjelde @sunxd3 @penelopeysm, anything missing here? If not, can we push to merge this?

[sunxd3]

as far as I can tell, we can introduce fix to AbstractPPL, and use it for predict.

On a higher level, we can also add predict(model, vector_of_params_and_weights) and support some kind of importance sampling so when predict, we don't need to go over all the posterior samples.

(I need to finish TuringLang/DynamicPPL.jl#651)

[sunxd3]

I think @sethaxen might be preoccupied, so I am taking over. Let me know if this is bad.

[sethaxen]

That's fine @sunxd3 , this has shifted way down on my priority list and I won't finish it anytime soon.

[sunxd3]

apologies for the ping, this might not be ready yet, but maybe time to take a look and start some new discussions

[torfjelde]

I guess the one question is whether we should perform decondition in predict or not?

[sunxd3]

I guess the one question is whether we should perform decondition in predict or not?

just saw the comment, sorry. I thought about the same thing, but unsure what is the right thing to do. The issue for me is that the dimension of the prediction might not match the dimension of the data.

How about we don't give a default implementation right now?

To clarify, the default implementations for the optional arguments should be included, but not

function StatsBase.predict(rng::AbstractRNG, T::Type, model::AbstractProbabilisticProgram, params)
    return rand(rng, T, fix(model, params))
end