Annotation comment

[spinkney]

If we had annotations described in design doc 33 I believe it is a nice solution to allowing users to pick a parameterization of a constraint (if we had it). For example, we can have multiple cholesky factor corr parameterizations with the default that we find to work best in most cases. However a user could select a different one from the default (again, assuming we have it written in Stan-math) as

model {
 cholesky_factor_corr[N] L; // use default no annotation necessary
 @param(stick_breaking) cholesky_factor_corr[N] L2; // this annotation tells the compiler to use the stick breaking parameterization that Stan currently uses 
}

@WardBrian

[WardBrian]

In the past we've talked about re-using <> for this, so your example would instead look like

model {
 cholesky_factor_corr[N] L; // use default no annotation necessary
 cholesky_factor_corr<transform=stick_breaking>[N] L2; // use the stick breaking parameterization that Stan currently uses 
}

I have a slight preference towards this more explicit style (especially since annotations are intended to be "ignore-able", but either would be implementable and it's definitely worth thinking about.

This was originally proposed by @syclik a few years ago when we were discussing how allowing compositions of lower/upper bounds and offset/multiplier exposes implementation details about which transforms are used, and he suggested one solution of that is to just intentionally expose the implementation detail and let people switch them out

[spinkney]

Cool, I just didn't know if we'd allow strings like that since all the other values users put in to <> are numbers

[spinkney]

I was thinking that the default parameterization would run if the annotation wasn't found or the compiler was told to ignore