rvar strange behavior about posterior

[avehtari]

Thanks! Of course, I forgot the binding order!

[mjskay]

The short answer is: all of these behaviors are correct, but the errors for the second cases could probably be better.

Long answer:

The first behavior is consistent with rvar broadcasting rules because you have:

• arg 1: as_rvar(c(0,1,2)): a constant (1-draw) rvar of length 3.
• arg 2: rdo(rnorm(1)): an rvar with the default number of draws (4000) and length 1.

The draws of arg 1 can be broadcast to 4000 (constant rvars can be used with other rvars of any number of draws) and the dims of both args (c(3) and c(1)) can both be broadcast to a common shape (c(3)).

What you're seeing in the second two examples is a result of the fact that |> binds more tightly than *, so the function being piped into is only being applied to the second arg. Since |> is translated into function application at the parser level you can check this with quote():

quote(as_rvar(c(0,1,2)) * rdo(rnorm(1)) |> str())
##as_rvar(c(0, 1, 2)) * str(rdo(rnorm(1)))

quote(as_rvar(c(0,1,2)) * rdo(rnorm(1)) |> draws_of())
## as_rvar(c(0, 1, 2)) * draws_of(rdo(rnorm(1)))

Thus in the first case, the output of str(rdo(rnorm(1)) (which is NULL) is cast to an rvar (giving rvar()), which does not have a compatible shape with as_rvar(c(0,1,2)).

In the second case, the output of draws_of(rdo(rnorm(1)) is cast to an rvar (giving a constant rvar of dim c(4000,1)), which also does not have a compatible shape with as_rvar(c(0,1,2)).

These errors could definitely be better... perhaps at least they should output the underlying expressions and also put the shapes in the same order as the arguments to make it easier to figure out what's going on.