-
-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
prior
and liklihood
model transforms
#159
Comments
How about storing the So, if the full model is: m = @model X,numFeatures,numGroups begin
@assert numFeatures == size(X,2)
β ~ Normal() |> iid(numFeatures, numGroups)
p = softmax.(eachrow(X*β))
y ~ For(eachindex(p)) do j
Categorical(p[j])
end
end Then I would expect the prior to be: @model numFeatures,numGroups begin
β ~ Normal() |> iid(numFeatures, numGroups)
end And the likelihood will be: @model X,numFeatures,numGroups begin
@assert numFeatures == size(X,2)
p = softmax.(eachrow(X*β))
y ~ For(eachindex(p)) do j
Categorical(p[j])
end
end It definitely would seem weird if the |
Models written like this are certainly easier to deal with. We can always put more responsibility on the users if we don't see a nice way for Soss to manage this sort of thing. So it's a sensible fallback. Ideally, I'd love to have it so users don't have to worry about this, and Soss will "do the right thing". |
Hmmm. If we don't have the user specify the number of features, then unfortunately the prior will depend on |
Or, at least the prior will depend on |
Are we happy with the behavior of
Also does julia> Soss.before(m, :β, inclusive = true, strict = true)
@model (X, numGroups) begin
numFeatures = size(X, 2)
β ~ Normal() |> iid(numFeatures, numGroups)
end miss the point? Defaulting Can you elaborate on how we might do this:
It seems interesting but I'm not sure I'm visualizing it right. |
Say you have a Soss model like
What would you expect
prior(m, :y)
andlikelihood(m, :y)
to look like?We haven't implemented
likelihood
yet, but forprior
we currently getIntuitively, I think I'd want this to only include dependencies of
β
(so nop
). It also feels wrong for the prior to includeX
. But the only way I see to get rid of it is to return a function "on the side" that's something likeThe I'm trying to be so careful here is that we need to be able to do this sort of thing programmatically, e.g. only "knowing" that a given model turns an
X
into ay
, so we can easily swap it out for another one.Any thoughts?
@millerjoey @DilumAluthge
The text was updated successfully, but these errors were encountered: