Julia-INLA

[Brian Parbhu]

Hi all,

My name is Brian Parbhu and I'm a Data Scientist who works in Healthcare. I would like to work on the Julia version of the R-INLA package that

is currently being used. Can anyone direct me to the Github or CRAN page. I'm just starting this and would like to understand what kind of dependencies the package

utilizes and if any are very R specific.

Thanks again and any help with this is much appreciated.

-Brian Parbhu

[Finn Lindgren]

Hi,

The r-inla.org website has a link to the bitbucket repository on

http://www.r-inla.org/download

Most of the code is written in C, but with some important processing in R code (Pre- and postprocessing, but also the rgeneric feature that allows defining latent models in the users R code).

My initial thought is that porting R-INLA to Julia would be a huge undertaking, especially since INLA keeps evolving.

Finn

On 29 Apr 2020, at 01:05, Brian Parbhu <brian....@gmail.com> wrote:



--
You received this message because you are subscribed to the Google Groups "R-inla discussion group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to r-inla-discussion...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/r-inla-discussion-group/b666299f-f685-4f1f-843d-9b56a64c17b9%40googlegroups.com.

[Helpdesk]

I agree with Finn.

If the aim is to make it _accessible_ from Julia, that might be easier,
as you might call R (directly or via shell) from Julia and then import
the results files. I don't know if there is already a Julia->R->Julia
interface available.

the INLA package works like the R-interface write the input/data files,
start the inla/fmesher-program (C/C++) in shell, do the calculations,
write the results to file, then R will read the results from these
files and construct the result object.

H

On Wed, 2020-04-29 at 01:12 +0100, Finn Lindgren wrote:
> Hi,
>
> The r-inla.org website has a link to the bitbucket repository on
> http://www.r-inla.org/download
>
> Most of the code is written in C, but with some important processing
> in R code (Pre- and postprocessing, but also the rgeneric feature
> that allows defining latent models in the users R code).
>
> My initial thought is that porting R-INLA to Julia would be a huge
> undertaking, especially since INLA keeps evolving.
>
> Finn
>
> > On 29 Apr 2020, at 01:05, Brian Parbhu <brian....@gmail.com>
> > wrote:
> >
> > 
> > Hi all,
> >
> > My name is Brian Parbhu and I'm a Data Scientist who works in
> > Healthcare. I would like to work on the Julia version of the R-INLA
> > package that
> > is currently being used. Can anyone direct me to the Github or CRAN
> > page. I'm just starting this and would like to understand what kind
> > of dependencies the package
> > utilizes and if any are very R specific.
> >
> > Thanks again and any help with this is much appreciated.
> >
> > -Brian Parbhu
--

Håvard Rue
Helpdesk
he...@r-inla.org

[brian....@gmail.com]

Sorry for the extremely late response, bad manners on my part. Lately I've had more time to revisit this again. 

Yes, I would be using Rcall.jl to do this so that all the work would be done in R and what the package

would be like is just a wrapper for the methods that you can call in INLA. 

[Dan B]

R-INLA seems quite slow in my experience, it would be great to have this recoded and run in Julia.

Brian are you progressing this idea?

Thanks

Dan

[Havard Rue]

The new version of mid December is hopefully better 

-- 

Håvard Rue 

hr...@r-inla.org

--
You received this message because you are subscribed to the Google Groups "R-inla discussion group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to r-inla-discussion...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/r-inla-discussion-group/5d07319e-2b24-4859-af49-ec1a559c7294n%40googlegroups.com.

[brian....@gmail.com]

I'm still interested in progressing it and also making it more friendly with a distributed computing framework like spark as well. I would welcome the opportunity to work with anyone who would want to do so as well.

I would also be interested in taking the same design approach and use it with something like dask and/or spark in conjunction with something like numba as well. To me if you were to do so, you would have something that I think

is more engineering-friendly, especially considering I haven't seen a Bayesian Inference framework work well with any distributed computing framework.

[brian....@gmail.com]

In python as well

[brian....@gmail.com]

Also, if we look into Python, it might be worth looking at BlackJAX as well.