statastan
statastan copied to clipboard
stan-dev
Support all CmdStan arguments and subarguments
Currently, not all CmdStan arguments are supported by StataStan (version 1.2.1), and the 'variational' method has yet to be implemented. However, the standard Stata syntax, used in stan.ado, would require one Stata option for every CmdStan (sub)argument, which is a lot of work. With nonstandard syntax though any number of arguments can be treated as one string, which StataStan could simply pass to CmdStan. In Stata, we need only convert the Stata-ish "arg1(val1) arg2(val2) ..." to "arg1=val1 arg2=val2 ...". So switching to nonstandard syntax would give StataStan users access to all of CmdStan.
It's a tradeoff between being natural for the user of Stata vs. easy to support. I'm OK either way and agree it would be nice to get all the Stan features out. But then it's also a matter of reading the outputs back in, as they're not all the same across sampling, optimization, and variational inference.
- Bob
On Jul 7, 2016, at 2:56 PM, Felix Leung [email protected] wrote:
Currently, not all CmdStan arguments are supported by StataStan (version 1.2.1), and the 'variational' method has yet to be implemented. However, the standard Stata syntax, used in stan.ado, would require one Stata option for every CmdStan (sub)argument, which is a lot of work. With nonstandard syntax though any number of arguments can be treated as one string, which StataStan could simply pass to CmdStan. In Stata, we need only convert the Stata-ish "arg1(val1) arg2(val2) ..." to "arg1=val1 arg2=val2 ...". So switching to nonstandard syntax would give StataStan users access to all of CmdStan.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
Hmm.. I should have said standard/nonstandard syntax parsing. To clarify, by nonstandard I meant nonstandard in the way Stata parses the arguments, and not in the sense that the user might find the syntax unnatural.
As an example, this might be considered very Stata-ish: command varlist, option1 option2 .... To write such a command using what Stata calls the standard syntax would parse option1 and option2 in two local variables. Using nonstandard syntax parsing, "option1 option2 ..." could be treated as a long string, which would be beneficial in this case. For the user, the syntax is identical.
I have written an intro here. There are three equivalent ways to run CmdStan from Stata (See methods 1-3). Equivalent in the sense that they would send identical commands to the shell; they call the same functions. Stata users should find methods 1 and 2 natural; method 3 is very close to CmdStan syntax, making it easy to just run the examples from the CmdStan guide. So in terms of calling CmdStan from Stata it's possible to have both all Stan features and Stata syntax natural for users.
I agree reading the outputs back in would require a different treatment for each method. While the arguments are not checked in Stata, I store a copy so Stata would know which method is used.
This all sounds absolutely great. I like the idea of getting the Stata code closer to the Stan code so that users can follow the examples without much mental translation. If I'm slow responding, it's because my wife and I are (literally) about to have a baby. But I am very supportive of this!
Congrats on your baby~ Hope everything went well.
Good to hear you like the idea. I'll work on it later this week.
On Mon, Jul 11, 2016 at 6:52 PM Robert Grant [email protected] wrote:
This all sounds absolutely great. I like the idea of getting the Stata code closer to the Stan code so that users can follow the examples without much mental translation. If I'm slow responding, it's because my wife and I are (literally) about to have a baby. But I am very supportive of this!
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/stan-dev/statastan/issues/15#issuecomment-231677125, or mute the thread https://github.com/notifications/unsubscribe/AEycOSpY1VGuaZo-Xw_vs4oPERWv4HEBks5qUgRTgaJpZM4JHZGA .