On Saturday, 20 February 2016 at 15:00:50 UTC, jmh530 wrote:
> On Saturday, 20 February 2016 at 13:31:03 UTC, bachmeier wrote:
>> On Friday, 19 February 2016 at 21:50:43 UTC, jmh530 wrote:
>>> On Friday, 19 February 2016 at 21:10:45 UTC, Dave wrote:
>>
>>> Alternately, you could try calling pystan or rstan from D. If you make any progress on these approaches, I would be interested.
>>
>> If it has an R interface, it also has a D interface using my rdlang project. I will look at it when I get some free time.
>
> R is the most popular way to use Stan I think. rstan is the library.

I looked at rstan. I've heard of it but never used it. AFAICT, the computationally intensive part is done by the call to stan() from within the R code. Therefore there are no efficiency issues with calling D -> R -> stan.

I took the easy road and ran the given R code directly. Here is my program:

import rinsided, rdlang.r, rdlang.vector;

void main() {
  evalRQ(`library(rstan)`);
  evalRQ(`y <- read.table('https://raw.github.com/wiki/stan-dev/rstan/rats.txt', header = TRUE)`);
  evalRQ(`x <- c(8, 15, 22, 29, 36)`);
  evalRQ(`xbar <- mean(x)`);
  evalRQ(`N <- nrow(y)`);
  evalRQ(`T <- ncol(y)`);
  evalRQ(`rats_fit <- stan(file = 'https://raw.githubusercontent.com/stan-dev/example-models/master/bugs_examples/vol1/rats/rats.stan')`);
  auto stanOutput = RVector(evalR(`attr(rats_fit, "sim")[[1]][[1]][[1]]`));
  stanOutput.print();
}

stanOutput is a D struct holding a pointer to that particular part of the output. Without more knowledge of rats_fit, I can't go further. You could also pass D data into R (y, x, xbar, ...) but I didn't see a reason to do that here. Nonetheless this is what you want, a way to call rstan from D, and then access the results from your D program.

On Saturday, 20 February 2016 at 20:39:58 UTC, bachmeier wrote:
>
> I looked at rstan. I've heard of it but never used it. AFAICT, the computationally intensive part is done by the call to stan() from within the R code. Therefore there are no efficiency issues with calling D -> R -> stan.
>
> I took the easy road and ran the given R code directly. Here is my program:
>

> }
>
> stanOutput is a D struct holding a pointer to that particular part of the output. Without more knowledge of rats_fit, I can't go further. You could also pass D data into R (y, x, xbar, ...) but I didn't see a reason to do that here. Nonetheless this is what you want, a way to call rstan from D, and then access the results from your D program.

Very cool!

I like and recommend Stan because you can fit types of models that would be very difficult to implement any other way. It was originally developed to fit hierarchical/multi-level models.

You're right that the computationally intensive part is not in R. You write a .stan file that contains the model you want to fit. Calling the stan function in R compiles the .stan file to C++ and runs, then it gives you some output.

rats_fit stores everything from when stan fit the rats.stan model to the data. The getting started page on github
https://github.com/stan-dev/rstan/wiki/RStan-Getting-Started
shows some of the key ways that you would interact with it. Print and plot. The extract function is also key. That's used to pull out the simulated values from the HMC.

On Friday, 19 February 2016 at 21:10:45 UTC, Dave wrote:
>
> Good starting points for a GSOC project would be "to port" mc-stan.org or some optimization algorithms from Coin-OR.org (please let me be more particular and independent of existing work if there is any interest for such a project!).

This is what I was talking about:
https://code.dlang.org/packages/libnlopt
https://code.dlang.org/packages/nloptd

On Monday, 22 February 2016 at 16:11:45 UTC, jmh530 wrote:
> On Friday, 19 February 2016 at 21:10:45 UTC, Dave wrote:

> This is what I was talking about:
> https://code.dlang.org/packages/libnlopt
> https://code.dlang.org/packages/nloptd

Cool stuff and an inspiring discussion how one can do numerics in D! For the GSOC project I was rather thinking of standalone D tools.

For the interested once, AdRoll implemented the BFGS optimization algorithm in D: https://github.com/AdRoll/lbfgs-d

The Stan Math Library is a header-only C++ library as Eigen is. Is there a chance to port such big libraries including many macros with htod (unfortunately I do not have a Windows-OS to try it out)?

On Monday, 22 February 2016 at 20:00:09 UTC, Dave wrote:
>
> The Stan Math Library is a header-only C++ library as Eigen is. Is there a chance to port such big libraries including many macros with htod (unfortunately I do not have a Windows-OS to try it out)?

On posix, you could try dstep. I ran htod on nlopt, but because it made some use of macros, I ended up having to make a bunch of adjustments myself. Afterwards, comparing what I did with what htod did, they were actually very close. I just wasn't familiar enough with how to do the conversation to notice it until I spent a lot of time learning about making the conversations.

You could also try Calypso. On that Qt MOC thread Elie Morisse complained about there not being enough testers. I'm sure creating other examples would be helpful or any other way to lend a helping hand.

On 2016-02-22 23:32, jmh530 wrote:
> On Monday, 22 February 2016 at 20:00:09 UTC, Dave wrote:
>>
>> The Stan Math Library is a header-only C++ library as Eigen is. Is
>> there a chance to port such big libraries including many macros with
>> htod (unfortunately I do not have a Windows-OS to try it out)?
>
> On posix, you could try dstep.

Unfortunately DStep cannot create bindings for C++. It also doesn't handle macros. Handle #define is work in progress.

-- 
/Jacob Carlborg