--- title: "Similar packages and comparison" output: rmarkdown::html_vignette vignette: > %\VignetteIndexEntry{Similar packages and comparison} %\VignetteEngine{knitr::rmarkdown} %\VignetteEncoding{UTF-8} --- ```{r setup, include = FALSE} knitr::opts_chunk$set( fig.width = 7, fig.height = 5 ) ``` ## Similar packages All packages discussed here are built on top of `{torch}`, R's native implementation of PyTorch. The torch package provides low-level tensor operations and neural network building blocks, but requires substantial boilerplate code for training. Higher-level packages like `{kindling}`, `{brulee}`, `{cito}`, and `{luz}` simplify this process while offering different features and design philosophies. `{kindling}` distinguishes itself through its unique code generation approach, versatile neural architecture support (can be expanded more in the future), and three-level API design. While `{brulee}` focuses on production-ready statistical models, `{cito}` emphasizes explainability and statistical inference, and `{luz}` provides adaptable training loops. `{kindling}` is different but not mutually exclusive to them: it offers deep architectural control and bridges the gap between torch code and tidymodels workflows. ### Package Comparison ```{r comparison_table, echo=FALSE} comparison = data.frame( Feature = c( "**Primary Focus**", "**Design Philosophy**", "**Architectures**", "**Code Generation**", "**tidymodels Integration**", "**Formula Syntax**", "**Layer-specific Activations**", "**GPU Support**", "**Explainability/xAI**", "**Statistical Inference**", "**Custom Loss Functions**", "**For whom?**" ), kindling = c( "Architectural versatility & flexibility, statistical modelling, and code generation", "Three-level API (code gen, training, ML framework (currently tidymodels) integration)", "Versatile — Feedforward Neural Networks (DNN/FFNN/MLP), Recurrent Neural Networks (RNN, LSTM, GRU), and more (in the future)", "Yes (inspect & modify torch code)", "Full (parsnip models & tuning)", "Yes", "Yes", "Yes", "Garson's & Olden's algorithms, vip integration, and more in the future", "Not yet implemented", "Yes", "Wanted versatile architectures (more in the future), fine-grained control, tidymodels users" ), brulee = c( "Production-ready statistical models", "Batteries-included with sensible defaults", "MLP, Linear/Logistic/Multinomial regression", "No", "Full (official tidymodels package)", "Yes", "No", "Yes", "Limited", "No", "No", "Wants standard supervised learning, stable production models" ), cito = c( "Statistical inference & interpretation", "User-friendly with comprehensive xAI pipeline", "Fully-connected networks, CNNs", "No", "No (standalone package)", "Yes", "No", "Yes (CPU, GPU, MacOS)", "Extensive (PDP, ALE, variable importance, etc.)", "Yes (confidence intervals, p-values via bootstrap)", "Yes", "Do ecological modeling, interpretable models, statistical inference" ), luz = c( "Training loop abstraction", "High-level API reducing boilerplate", "Any torch nn_module", "No", "No (standalone package)", "No (uses torch modules directly)", "No (also uses torch modules directly)", "Yes (automatic device placement)", "No", "No", "Yes", "Wants custom architectures, users needing human-friendly training loop control" ), stringsAsFactors = FALSE ) knitr::kable( comparison, col.names = c("Feature", "kindling", "brulee", "cito", "luz"), label = "Table of comparison" ) ``` ## Complementary Use These packages aren't mutually exclusive. You can use `{kindling}` and `{brulee}` for production MLPs, except `{kindling}` provides RNNs. The `{cito}` package is when you need oriented model interpretation. Then, the `{luz}` package is ideal when you want less verbose training loops. Despite the difference between the philosophies and main usage, all integrate with or build upon the torch ecosystem, allowing you to switch between them as your modeling needs evolve. For instance, prototyping with `{kindling}` to explore different network architectures is much easier, as well as deploying its models for production, just like `{brulee}`, but `{cito}` is when stakeholders need detailed explanations of model predictions.