-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feature request: unicode in source #95
Comments
Comment by ariddell Python 2 handles UTF-8 fine. (It's just not the default representation.) |
Comment by bgoodri RStudio should work https://support.rstudio.com/hc/en-us/articles/200532197-Character-Encoding |
Comment by ariddell @tpapp https://docs.python.org/2/howto/unicode.html Python 3 uses Unicode by default. In Python 2 you need to be explicit about it. In both cases you can have unicode strings in source code. |
Comment by ariddell Here's a link to the section: https://docs.python.org/2/howto/unicode.html#unicode-literals-in-python-source-code |
Comment by bob-carpenter Those are unicode literals, not unicode identifiers. Can you have éø = 10 where you assign to a unicode literal? Or dictionaries
|
Comment by ariddell You're right. In Python 2.7 you can't have unicode variables. In Python 3 you can. But why does that matter? We only need unicode in the Stan program code. (Parameter lookups aren't affected since keys are and always were strings.) |
Comment by bob-carpenter It looks like you use a dictionary structure for variable schools_dat = { Can the keys be unicode? RStan can read data values out of the environment if they're
On May 11, 2016, at 4:07 PM, Allen Riddell [email protected] wrote:
|
Comment by ariddell Python 2 has no problems with unicode dictionary keys. In fact, it can
( Bref, there is nothing Python 2 can't do that's relevant to supporting On 05/11, Bob Carpenter wrote:
|
Comment by bob-carpenter
You should have edit permission on the issues.
|
Comment by tpapp @ariddell: The table was accurate, but since not all Stan interfaces work the way that R/Julia does, I extended it with the information that is probably most relevant: whether the interfaces, in the way they currently operate, would support UTF8 variables for (1) passing data to Stan and (2) extracting MCMC results. Thanks for pointing this out, this is much more important than the details of UTF8 support in those languages per se. Not being a STATA user, I am reluctant to make a definitive statement about it. If someone could help with that it would be great. |
Comment by ariddell One use of unicode in Stan Program code which should definitely be supported is in comments. Leaving code comments in one's native language is fairly routine in Python/Java/etc. We should at least support that in Stan. |
Comment by bob-carpenter Unicode in comments is OK now.
On May 14, 2016, at 7:28 PM, Allen Riddell [email protected] wrote:
|
Comment by tpapp Indeed UTF8 comments work fine, and I have been using them for a while. Made a clarification in the issue. |
Comment by ariddell UTF8 comments aren't supported in PyStan right now (non-ASCII characters will generate an error). I'll fix this. stan-dev/pystan#223 |
Issue by tpapp
Monday May 09, 2016 at 17:29 GMT
Originally opened as https://github.com/stan-dev/stan/issues/1888
Introduction
Some languages now support Unicode (mostly UTF8) for writing source code. It would be great if one could also use Unicode in Stan source. (Note that comments in UTF8, or any superset that embeds ASCII, are already supported in the sense the parser just ignores them.)
Broadly, there are two possible levels of support:
ϕ
), and≤
), which provide synonyms for existing ones (eg<=
)Example
This is how the 8 schools example would look like in unicode:
Possible benefits
Possible downsides
The first two are mitigated by the fact that ASCII is a subset of UTF8, so using the feature is optional.
UTF8 support in various languages which have interfaces for Stan
Editor support
Emacs
See this list for various UTF8 implementations using autocomplete, company-mode, and quail.
See also
The text was updated successfully, but these errors were encountered: