Brian Ward

Results 559 comments of Brian Ward

This is very exciting! A few general thoughts, right off the bat: 1. I tend to find it much easier to read/type command line arguments that `--look-like-this` (so called kebab-case)...

The wording of the issue isn't clear to me if you're asking someone else to document this or if it's just a TODO item for yourself, so forgive me if...

Note that this is also important in e.g. `transformed parameters` ```stan parameters { array[3] real y; } transformed parameters { corr_matrix[size(y)] z; } ``` generates the same error, since `size(y)`...

We could allow that in transformed data, but not generated quantities. My guess is it was just easier to disallow everywhere

We probably shouldn’t send stderr to /dev/null like we currently do in build.py

Happy to make it print failures. I can build all documents/formats locally without error, so I don't believe it is an issue of what is checked into the repo

The colon in indexing isn't really an operator in Stan, since we don't allow `1:2` as an expression, only as part of for loops multi-indexing. We could put it in...

I believe this is stated further down on the page you link, https://mc-stan.org/docs/reference-manual/vector-matrix-array-expressions.html#no-empty-array-expressions

Is there anything more you think we should be saying in that section?

The vectorized versions are currently documented elsewhere: https://mc-stan.org/docs/functions-reference/vectorized-accessor-functions.html#real-and-imaginary-component-accessor-functions We could unify these, but there's a bit of extra explanation on the types that is nice to call out