Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Ricardo Vieira
    @ricardov94:matrix.org
    [m]
    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
    brandonwillard
    @brandonwillard:matrix.org
    [m]
    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
    brandonwillard
    @brandonwillard:matrix.org
    [m]
    I'm thinking of censoring
    Ricardo Vieira
    @ricardov94:matrix.org
    [m]
    Ah. We might need to also infer logcdfs for derived RVs, right now we only do it for logprobs
    brandonwillard
    @brandonwillard:matrix.org
    [m]
    anyway, that truncation PR is a great addition
    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
    Ricardo Vieira
    @ricardov94:matrix.org
    [m]
    I can push updates tomorrow
    brandonwillard
    @brandonwillard:matrix.org
    [m]
    Ricardo Vieira, take a look at aesara-devs/aeppl#129 when you get a chance
    I think it could be a viable solution for now
    Ricardo Vieira
    @ricardov94:matrix.org
    [m]
    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
    Ricardo Vieira
    @ricardov94:matrix.org
    [m]
    Is there a term for > unary operator?
    multinary? xD
    brandonwillard
    @brandonwillard:matrix.org
    [m]
    Ricardo Vieira at some point soon, we need to formalize the IR and rules in AePPL
    for example, see the description in this paper: A Calculus for Probabilistic Languages
    brandonwillard
    @brandonwillard:matrix.org
    [m]
    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
    Ricardo Vieira
    @ricardov94:matrix.org
    [m]
    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
    brandonwillard
    @brandonwillard:matrix.org
    [m]
    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
    Ricardo Vieira
    @ricardov94:matrix.org
    [m]
    Do value variables in Aeppl need to be "pure-input" variables or can they be anything really (subtensor, exp(input)...)?
    brandonwillard
    @brandonwillard:matrix.org
    [m]
    it should be possible to provide anything as a value variable, really
    brandonwillard
    @brandonwillard:matrix.org
    [m]
    Ricardo Vieira, have you found an issue with such value variables?
    Ricardo Vieira
    @ricardov94:matrix.org
    [m]
    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
    brandonwillard
    @brandonwillard:matrix.org
    [m]
    yeah, if you have any issues, it's a bug
    Ricardo Vieira
    @ricardov94:matrix.org
    [m]
    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])
    brandonwillard
    @brandonwillard:matrix.org
    [m]
    can you show the debug print for 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
    Ricardo Vieira
    @ricardov94:matrix.org
    [m]
    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
    Ricardo Vieira
    @ricardov94:matrix.org
    [m]
    Would be good to get this one reviewed/merged, I have some ongoing work that depends on it: aesara-devs/aeppl#146
    Ricardo Vieira
    @ricardov94:matrix.org
    [m]
    Tagged a new release. Things are getting more wild with nested logprob derivations: https://github.com/aesara-devs/aeppl/releases/tag/v0.0.31
    brandonwillard
    @brandonwillard:matrix.org
    [m]
    wild how?
    good, bad?
    Ricardo Vieira
    @ricardov94:matrix.org
    [m]
    Very good
    brandonwillard
    @brandonwillard:matrix.org
    [m]
    ah, nice
    Ricardo Vieira
    @ricardov94:matrix.org
    [m]
    Much more expressiveness
    brandonwillard
    @brandonwillard:matrix.org
    [m]
    definitely
    and there's a lot more to come
    Ricardo Vieira
    @ricardov94:matrix.org
    [m]
    Something on your radar?
    brandonwillard
    @brandonwillard:matrix.org
    [m]
    many things