I still like the idea of passing the non-default update together with the main output, perhaps in the
tag and not as a property
but the question about updates handling when truncations are inferred from regular Aesara tensor
Ops
1 reply
although I think that shouldn't be an issue, because there are no RNGs to update when log-probabilities are derived or computed
Ah. We might need to also infer logcdfs for derived RVs, right now we only do it for logprobs
I'll be looking into efficient zero-truncated beta-binomial samplers soon, so it would be good to have it merged so that the work can be done in that context
I think it could be a viable solution for now
Yeah I read it. I had a different idea in mind but I like this one more. Let's go ahead and revisit if problems emerge
multinary? xD
for example, see the description in this paper: A Calculus for Probabilistic Languages
in other words, we're growing a body of
types upon which we perform rewrites and expect/assume specific things
we can formalize those things and reason about them before implementing them
that will help us catch fundamental issues and better understand/assess what can and cannot be represented due to our choices
e.g. the soundness and consistency of our logic
That paper was quite interesting, even though I am able to digest the details having no background in this type of presentation
Silly question, are they using the square as symbol or is my PDF not rendering properly xD
it renders as a square for me too, so I'm assuming it's supposed to be there
I've seen its use in type theory papers (e.g. as the type of all kinds)
but that doesn't appear to be its use here
Do value variables in Aeppl need to be "pure-input" variables or can they be anything really (subtensor, exp(input)...)?
it should be possible to provide anything as a value variable, really
No I haven't found a problem, but I haven't tried anything crazy either. Good to know that in principle there shouldn't be restrictions
Because sometimes we might want to, say model the errors and not the observations, so the value variable might be a difference of a constant and some other values variables
So this does not work, x is not replaced by its value in the logp term of y:
import aesara
import aesara.tensor as at
import aeppl
x = at.random.normal(name="x")
y = at.random.normal(name="y")
x_vv = x.clone()
y_vv = y.clone()
logp = aeppl.joint_logprob({x: x_vv, y: y_vv+x})
assert y not in aesara.graph.basic.ancestors([logp])
regardless, it should only use the value
y_vv + x for y
it shouldn't necessarily replace the
x in y_vv + x with x_vv
it definitely isn't designed to do that
and I'm not sure how it makes sense semantically
Thinking strictly of what goes into the logp function it should be the same as if x had been the
loc of y.
But there is no dependency in the generative graph, so I am also not convinced this should work
Would be good to get this one reviewed/merged, I have some ongoing work that depends on it: aesara-devs/aeppl#146
Tagged a new release. Things are getting more wild with nested logprob derivations: https://github.com/aesara-devs/aeppl/releases/tag/v0.0.31
good, bad?
and there's a lot more to come