R interface

[astamm]

Following up on our first attempt at an R interface of GUDHI (https://lmjl-alea.github.io/rgudhi/), I would like to take the opportunity that the package {rgudhi} has been archived by CRAN at the moment to better think together how it should be structured.

The original implementation was meant to mimic the Python interface and thus keep classes and all possible portable modules to R.

However, R users generally are not familiar with the concept of classes and rather prefer working with functions.

Furthermore, it is likely that they will have more expertise with the data science side of things rather than the computational geometry side. This means that they will likely use TDA as a way to produce topological features to feed machine learning models, but without the knowledge or expertise to best choose hyper parameters to go from a point cloud or a function or else to a persistence diagram or one of its possible representations.

That raises the question of whether we should keep {rgudhi} structured as a mimic of the Python interface. On the top of my mind, here are a few ideas/questions that I have and on which I'd like your inputs:

1. Should an R interface mimic the Python interface?
2. Could we propose sensible default choices to go from inputs to persistence diagrams? (including choice of the complex to use, its hyper parameters )?
3. Should we focus on porting functions or classes? Does the Python interface systematically provide both?
4. @corybrunson and I managed to get a grant from the R consortium to design a tdaverse which is an opinionated collection of R packages to perform TDA in R, with the idea that each package performs one task. We currently have developed and published on CRAN 4 packages. Two of them are low-level packages, one is {phutil} which defines a data structure to host persistence data and functions to compute Bottleneck and Wasserstein distances between diagrams, the other is {ripserr} which is an R interface to the C++ ripser library. The last two packages are at higher level. {inphr} implements hypothesis testing for samples of persistence diagrams. {tdarec} is an extension to produce TDA features for machine learning pipelines within the tidymodels ecosystem which is the R equivalent to scikit-learn. I am mentioning all of this because the R interface of GUDHI could become an engine at several levels of these packages: as an alternative to {ripserr} to compute a Rips filtration, as an alternative to {phutil} to compute distances, as a way to do clustering, as an alternative to {tdavec} to compute vectorisations of persistence data, etc. This could then impact the way we want to structure the R interface of GUDHI.
5. Last, how we should handle the way seeds and random number generators are handled to ensure reproducibility of results of a statistical analysis. Should it be on the side of the original language in which the original library has been developed (here C++) or on the side of the receiving language, i.e. the language for which we are making the interface? This is related to the current PR Gudhi random generator for reproducibility #1280.

All thoughts are welcome! Tagging here a few people I know in addition to @corybrunson: @VincentRouvreau @mglisse. Don't hesitate to ping more people into this discussion!

[hschreiber]

I don't have any experience with R, nor do I know how much work it is to bind python to it, so my opinion is only based on the python/C++ binding experience I have (and therefore have to be taken with an important grain of salt):

1. I think that the R interface should resemble the usual R usage and not mimic the python interface. Even if a same person uses both, I don't think he should expect them to work the same. In particular, because some of the python interface of Gudhi are already mimicking the C++ interface. And, now with the hindsight, we regret it a bit, as it confuses python users more that it helps them (they mostly have no C++ experience).
2. Hm, that it more difficult to say. Perhaps the more sensible choice would be to use as default parameters the most used ones? As the "most optimized" ones vary a lot from case to case. Except if the inputs in R are all very similar ? For example, if you have point clouds in low dimensions, the Alpha Complex would often be the best choice, etc.
3. Currently, the Python interface does not provide both systematically. But this will perhaps change with some other modifications we are working on now.
5. The best would that reproducibility works on every layer: C++, Python and R. As it is an important concept independently of the language. And if reproducibility works in Python, it makes the work easier in the R bindings (I guess). As you pointed out, PR Gudhi random generator for reproducibility #1280 is a first step in this direction (as seeds can be passed as integers, there is not even a real need to interface GudhiBitGenerator, except if you have extra R methods which needs it).

[astamm]

Thanks for these helpful comments @hschreiber!

[corybrunson]

@astamm thanks for tagging me! For context, i have plenty of R experience but only as little C++ and Python experience as i can get away with while having to use them for certain tasks.

1. It would help me a lot to see a few examples of how the C++ and Python interface compare on the same tasks. I tried looking into the documentation, but i couldn't find any such "side-by-side" comparisons. This is what i would find most appropriate: (i) At a low level, the R interface should follow standard R syntactic conventions—though that would include e.g. the new S7 system. (ii) At a high level, the R interface should rely on the same concept map as the C++ code, so that a user familiar with both languages would quickly learn how to write a task in R that they know how to do in C++. (Maybe all this is obvious and you're asking about more subtle, less user-facing details?)
2. How are argument defaults handled in C++, if at all? My outlook is that almost every R function for which an appropriate default value can be set (or inferred from other arguments) should use that default value. Details can get messy, but those can be worked out over time.
3. It makes sense to me to export classes as well as functions, insofar as they can be wrapped using {Rcpp} or {cpp11}. One reason, and this has implications for other design choices, is that the R users who use {rgudhi} directly are likely to either be doing standard, well-documented tasks (or using it under the hood, as an engine for {inphr}/{tdarec} tasks for example) or be TDA specialists, so it's OK to expose some of the more technical innards. Indeed, that would be highly valuable to the specialists and perhaps informative to other users, provided it doesn't hold up their work (hence the importance of good documentation for standard tasks).
4. Additional note: The TDAverse idea traces back to @rrrlw who originally wrote the {ripserr} binding and other early TDA packages.
5. I have no background here but am interested to follow the discussion. : )

[astamm]

Thanks @corybrunson for your valuable insights as always!