Annotation comment

Open
#55 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Stale
Domain
compilers

Research direction

Start with design doc 33, then review the annotation example in this issue and the referenced Stan-math parameterizations. Done would require a decided annotation design and clear compiler behavior for selecting an alternate constraint parameterization.

Written by the indexing model from the issue text.

Description

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

Dominant language
No language data
Stars
41
Forks
30
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from stan-dev/design-docs

All issues in stan-dev/design-docs

Similar issues

More Compilers issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.