Carlos Parada

> You can `convert` nearly every `Fixed` number into a `Rational`, but not vice-versa. If we made this change, we might get errors that currently aren't a problem. Are you...

@oschulz I see `sqrt` and `square` are defined as inverses, even though this isn't strictly correct; is the plan to allow partial inverses (e.g. trig/hyptrig) functions to be defined as...

> I agree this change should be made If that's the case, better sooner than later I think. The longer we wait the more likely it is someone will depend...

> I implemented something for `@concrete` to basically commute with any other well-implemented struct def macro by internally shuffling around the order in which the macros are applied. > >...

@theogf any progress?

> > I don't think this has to or should be couple to a PPL. For instance, for algorithm 2 it seems one just needs to provide functions that sample...

> The functions currently assume draws are in a single array with shape `(draws, chains, params)`, like `MCMCChains.Chains` stores. We should consider how to support different permutations (could be as...

> I should add that I don't think we have to stick with the current convention but it would be good to be consistent for 3d arrays. I guess the...

I think the best arrangement would be `(parameters, draws, chains)`. Operations on chains are usually done in parallel, e.g. sampling a different chain on each core, so it's not necessary...

> No, it's not supported by `ess_rhat`. All functions either work with vectors or arrays of shape (draws, chains, params), but not both. I believe `ess_rhat` currently uses `(draws, params,...