我也是。但是像@gsk3一样,我使用“ Rcpp 刻度”来度量它,因为我希望将富 R 对象传递给 Julia。现在看来,这种说法完全没有得到支持。
Julia 有一个漂亮而简单的 C 接口。所以我们得到了类似 .C()的东西。但是正如最近在 r-devel 上所讨论的,您实际上并不需要 .C(),在大多数情况下,您更愿意使用 .Call()来传递表示真实 R 对象的实际 SEXP 变量。所以现在我看不到 R 代表 Julia 的空间,因为这个限制。
也许在 Julia 稍微成熟一点,我们得到一个合适的 C + + 接口之前,可以先开始使用 tcp/ip 到 Rreserve 的间接接口。或者我们使用一些基于 Rcpp 的东西从 R 到 C + + ,然后再进入一个中间层(必须有人编写) ,从中向 Julia 提供数据,就像实际的 R API 只提供一个 C 层一样。我不知道。
一天结束的时候,我们可能需要一些耐心。我是在1996年或1997年左右开始研究 R 的,当时 Fritz Leisch 在 comp.os.linux.Declaration 新闻组上发布了第一个公告。当时 R 的设备相当有限(当然,如果我们知道我们有一个赢家的话,那么 S 语言的全部前景就是完美的)。几年后,我准备把它作为我的主要建模语言。当时 CRAN 还有不到100个包裹..。
茱莉亚很可能到达那里。但就目前而言,我怀疑我们中的许多人会用 R 语言完成工作,并且会对茱莉亚有一些好奇的瞥见。
您可能还想了解我的尝试: JuliaConnectoR R 包。该包可从 GitHub和 CRAN获得。
它的目标是在 R 中直接从 Julia 导入函数,这样它们就可以像 R 代码中的 R 函数一样使用。Julia 函数的返回值被转换成 R 数据结构,可以在 R 中使用,也可以传递回 Julia。
对于 Julia 和 R 的进一步集成,也可以通过将 R 函数作为回调函数传递来从 Julia 回调到 R。
与 XRJulia 类似,JuliaConnectoR 依赖于 TCP,但它是面向功能的,并使用优化的自定义流格式,而不像 XRJulia 那样使用基于文本的 JSON 消息。
TCP 通信的一个优点是对不同版本的 Julia 和 R 的稳定性。对于像 RCall 和 JuliaCall 这样的 C 接口级别的集成来说,要维护这一点要困难得多。