Bob Carpenter

> Allowing the target to be modified within the transformed parameter block makes Stan programs harder to parse overall. I take it you mean for a human reader, not stanc3....

> Steve it seems what you’re trying to do is allow for user-defined types. Yes, something like that. There's an issue of how the Jacobian and inverse can share computation...

Absolutely. I designed the language so that users could focus on the constrained space (1) and algorithms could focus on the unconstrained space (3). Unfortunately, that abstraction is leaky when...

> The centered and non-centered parameterizations are different parameterizations and hence defined by _different_ Stan programs. Exactly. So I don't see why you say the user doesn't have to think...

> I believe that the design of the language introduces a fundamental difference between unconstraining transformations, X subset R^N -> R^M and 1-1 transformations R^M -> R^M. Both the language...

Not fully. We really want to have syntax for general mixtures, not necessarily as described in this issue. We can brainstorm about possible syntaxes in person, but I think it...

> Let's get this to work with multiplier and offset too. I think multipliers would make sense here, but I don't see how offset would help with the sum-to-zero constraint.

I ran some more experiments to compare the `alpha[1] = 0` approach vs. the `alpha[N] = -sum(alpha[1:N-1])` approach. In both cases, we put a prior on the constrained to sum-to-zero...

@spinkney: I think we need to remove that translation bit as I don't think it makes sense here. I hadn't realized someone had worked out the reduction in scale as...

I think the general problem with the SVD-based and QR-based approaches is that they imply doing calculations with data/transformed data. This would be painful to do with our current architecture...