HN user

marcle

195 karma
Posts8
Comments34
View on HN

My go-to projects have varied over time:

1. An implementation of Fisher's exact test for 2x2 tables. This adapts the algorithm from R's fisher.test() function, which was implemented with function closures for optimisation, which does not always map well to other languages.

2. A foreign function interface to the Rmath library. I have now done this for Standard ML (MLton, Poly/ML, Moscow ML, MLkit, SML/NJ, SML# and Manticore), OCaml, Ur/Web, Mercury and MonetDB. Code generation sometimes uses cpp, m4 or the language's tree and string facilities.

3. Discrete event simulation using message passing with an application to cost-effectiveness analysis. Someday, I'll get this published.

Another relevant software category is the statistical analysis languages, including SAS, Stata and SPSS.

Old-school SAS included only two data types (floats and character strings), but allowed for SQL and sequential data-steps to live together. Persistence was baked in. The floats could be used to represent dates, datetimes and other formats. I particularly appreciated being able to use macros to define a data-step view to split the follow-up for an individual from a table. Such a view could then be collapsed using SQL. More recently, R tools such as dplyr have brought together data-frames and relational operations. However, I miss the sequential coding in SAS, using macros as higher-level tools to define the logic, including corner cases.

For strictly typed records, I have always wanted to spend more time with SML# [0] this allows for record updating, with close ties to SQL -- an under-appreciated version of SML.

[0] https://github.com/smlsharp/smlsharp

TLDR: Arrow and DuckDB provide fast database aggregates compared with R's RDS format and, to an extent, SQLite.

It is unclear how much functionality is available for Arrow under R: any comments? It would also be interesting to see a similar benchmark for Python, which could include the embedded version of MonetDB -- an R package for MonetDB/e is not yet available.

Edit: amended the TLDR to reflect jhoechtl's and wodenokoto's comments. SQLite provided reasonably memory efficient aggregates.

A short answer: this requires a basis matrix for the splines rather than interpolation.

A longer answer: the splines require a basis matrix B(t), do that g(S_0(t))= B(t) gamma for a vector of parameters gamma and some transformation g of survival. A classical choice would be to use M-splines and I-splines with g(S)=-log(S) and a penalised likelihood, with the constraint that the gammas should be increasing. In R, this would use the splines2 package, while in Julia, one could use the splines2.jl package (disclaimer: which I maintain). The computational challenge is that the basis matrices need to be re-evaluated for changes in the coefficients for the covariates (that is, the betas).

There is no free lunch:).

I remember spending a summer using Template Model Builder (TMB), which is a useful R/C++ automatic differentiation (AD) framework, for working with accelerated failure time models. For these models, the survival to time T given covariates X is defined by S(t|X) = P(T>t|X) = S_0(t exp(-beta^T X)) for baseline survival S_0(t). I wanted to use splines for the baseline survival and then use AD for gradients and random effects. Unfortunately, after implementing the splines in template C++, I found a web page entitled "Things you should NOT do in TMB" (https://github.com/kaskr/adcomp/wiki/Things-you-should-NOT-d...) - which included using if statements that are based on coefficients. In this case, the splines for S_0 depend on beta, which is this specific excluded case:(. An older framework (ADMB) did not have this constraint, but dissemination of code was more difficult. Finally, PyTorch did not have an implementation of B-splines or an implementation for Laplace's approximation. Returning to my opening comment, there is no free lunch.

As an older user of SAS (from 1990) and R (from 1998), this may finally push academia away from SAS.

Locally, we continue to use SAS for manipulation of linked health and population registers. The combination of the SAS data step, SQL and macros is powerful for more complex data. However, most of our researchers use R or Stata for data analysis.

That said, younger researchers often prefer to use dplyr or data.table in R for the data management. One challenge is that those researchers often can not read the legacy SAS code - hence they do not understand how to handle the corner cases. This may be a symptom that data management documentation is often poor in academia.

For data analysis of time-to-event data, Python and Julia both lag behind R, Stata and, to an extent, SAS. I would be happy to move to Julia, but some of the basic modelling tools (e.g. safe prediction for formulae with splines) are currently lacking.

I am often amazed that one can run Maxima on an Android phone (Maxima on Android), including Gnuplot graphics and MathJax math formulae:

  plot3d ([cos(x)*(3 + y*cos(x/2)), sin(x)*(3 + y*cos(x/2)), y*sin(x/2)], [x, -%pi, %pi], [y, -1, 1], ['grid, 50, 15]);

  /* gradient of the log-likelihood for a time-dependent accelerated failure time model */
  assume(t>0)$ H:-log(S(integrate(exp(alpha+beta*x(u)),u,0,t))); diff(delta*diff(H,t)-H,beta);
Axiom/Fricas is a beautiful language which provides a powerful mathematical type system.

This is a very interesting addition to the embedded analytics database landscape. MonetDB/e may hit a sweet spot.

I always enjoyed using MonetDBLite (with R), but it is no longer being developed. I understand that CWI has contributed to the development of MonetDBLite, DuckDB and MonetDB/e. It would be useful to know how DuckDB and MonetDB/e differ. The latter may have the advantage of building on a well established server.

For some other embedded databases, see http://embedded-database.com/open-source-embedded-database-s....