Submitting Author Name: Antoine Soetewey
Submitting Author Github Handle: @AntoineSoetewey
Other Package Authors Github handles: @joshuamarie
Repository: https://github.com/joshuamarie/kindling
Version submitted: v0.3.2
Submission type: Stats
Badge grade: silver
Editor: TBD
Reviewers: TBD
Archive: TBD
Version accepted: TBD
Language: en<!--end-language--
- Paste the full DESCRIPTION file inside a code block below:
Package: kindling
Type: Package
Title: Higher-Level Interface of 'torch' Package to Auto-Train Neural Networks
Version: 0.3.2.9000
Authors@R: c(
person("Joshua", "Marie",
email = "joshua.marie.k@gmail.com",
role = c("aut", "cre")),
person("Antoine", "Soetewey",
email = "antoine.soetewey@uclouvain.be",
role = "aut",
comment = c(ORCID = "0000-0001-8159-0804"))
)
Description: Provides a higher-level interface to the 'torch' package for defining,
training, and fine-tuning neural networks through code generation.
The package supports several architectures, including feedforward
(multi-layer perceptron) and recurrent neural networks (RNN, LSTM,
GRU), while reducing boilerplate 'torch' code. Model training
methods also bridge to machine learning frameworks in R,
particularly the 'tidymodels' ecosystem, including 'parsnip' model
specifications, workflows, recipes, and tuning tools.
License: MIT + file LICENSE
Encoding: UTF-8
LazyData: true
Imports:
purrr,
torch,
rlang,
cli,
vctrs,
tibble,
stats,
NeuralNetTools,
ggplot2,
hardhat,
lifecycle,
coro
Suggests:
testthat (>= 3.0.0),
dplyr,
tidyr,
magrittr,
box,
recipes,
workflows,
parsnip (>= 1.0.0),
tune,
dials,
rsample,
yardstick,
mlbench,
modeldata,
nnet,
vip,
knitr,
rmarkdown,
DiceDesign,
lhs,
sfd,
covr,
fansi,
withr
SystemRequirements: LibTorch (>= 1.13, via torch::install_torch())
Additional_repositories: https://cran.r-universe.dev
Remotes: cran/vip@0.4.6
Config/testthat/edition: 3
Roxygen: list(markdown = TRUE, roclets = c ("namespace", "rd", "srr::srr_stats_roclet"))
Depends:
R (>= 4.1.0)
URL: https://kindling.joshuamarie.com, https://github.com/joshuamarie/kindling
BugReports: https://github.com/joshuamarie/kindling/issues
VignetteBuilder: knitr
Config/roxygen2/version: 8.1.0
Scope
Pre-submission Inquiry
General Information
- Who is the target audience and what are scientific applications of this package?
R users already working in the tidymodels ecosystem (researchers, applied statisticians, data scientists, students) who want to fit and tune feedforward or recurrent neural networks without hand-writing torch model/training-loop code, while still being able to inspect, modify, or extend the generated torch code directly. Applications include predictive modeling on tabular and sequential data, teaching neural-network fundamentals with inspectable generated code, and research workflows that need tidymodels-standard resampling/tuning/evaluation applied to deep learning models.
kindling falls under the third category:
An improvement on other implementations of similar algorithms in R.
The underlying algorithms — feedforward neural networks (MLP/DNN/FFNN) and recurrent variants (RNN, LSTM, GRU) — are well established and are not novel; kindling does not implement them from scratch either, but builds directly on {torch}'s tensor and autograd engine, itself R's binding to the LibTorch/PyTorch C++ backend. Nor is kindling the first R interface to torch-based neural networks: several higher-level packages already fill that role, most notably {brulee} (tidymodels' own torch engine, now covering MLPs, linear/logistic/multinomial regression, and several tabular deep-learning architectures — ResNet, SAINT, TabICL, AutoInt — plus a pretrained forecasting wrapper), {cito} (focused on explainability and statistical inference, with fully-connected and convolutional architectures), and {luz} (a general training-loop abstraction over arbitrary, user-authored torch modules). Earlier, pre-torch neural network implementations in R include base R's nnet and {neuralnet}.
kindling's contribution relative to these is in interface design, not algorithmic novelty:
- Code generation as a first-class, inspectable layer. kindling's
nn_module_generator() (and the higher-level ffnn_generator()/rnn_generator()) return the actual torch::nn_module() expression as an object a user can print, modify, and re-evaluate before training. By contrast, brulee and cito construct their nn_module()s internally inside their fitting functions (e.g. brulee's mlp_module is defined once, package-side, and instantiated inside mlp_fit_imp(); cito's build_model() does the equivalent), with no inspectable intermediate step; luz takes the opposite approach and requires users to author the nn_module themselves, providing no generation at all.
- Recurrent architectures as a first-class citizen alongside feedforward ones, via
rnn()/rnn_generator()/rnn_kindling() supporting RNN, LSTM, and GRU cells with a configuration surface shared with the feedforward path (hidden_neurons, layer-specific activations, nn_arch() for custom layer types). None of brulee, cito, or luz ship a built-in recurrent layer.
- Deeper
{tidymodels} integration for recurrent models specifically, via a dedicated parsnip engine (rnn_kindling()) with full dials/tune hyperparameter-tuning support — an architecture family none of the compared packages expose through tidymodels at all.
Not applicable: kindling is a general-purpose modeling framework that does not collect, store, or process personal, sensitive, or human-subjects data itself; any data privacy considerations depend entirely on what data a user chooses to train on.
Badging
- What grade of badge are you aiming for? silver
We are targeting silver. kindling fulfils at least two of the four aspects listed for silver:
1. Compliance with a good number of standards beyond the minimal set. Every General and ML standard we identify as applicable is met: 56/56 applicable General standards and 60/60 applicable ML standards (100%), with the remaining 12 General and 30 ML standards tagged @srrstatsNA and individually justified — none left as @srrstatsTODO. Counting all general+ml standards together (158 total, including the justified-NA ones), that is 116/158 = 73.4% overall compliance, comfortably above the "more than one half" bar for this aspect. srr::srr_stats_pre_submit() confirms the package as fully documented against the current standards, and the automated check on the pre-submission thread independently reports the same figures.
2. Excellence in at least two broad sub-categories — specifically documentation and testing, which is the guide's own illustrative example for this aspect:
- Documentation (General standards, sub-category 1.x): primary references and a Life Cycle Statement; five vignettes covering getting started, hyperparameter tuning, custom activation functions, and — going beyond what standards require — a dedicated comparison against similar packages (
{brulee}, {cito}, {luz}) and a worked demonstration that a zero-hidden-layer network recovers OLS/logistic regression as a special case; ?train_nn carries dedicated sections on training/validation/test data semantics, the missing-value policy (with a runnable {recipes} imputation example), and guidance on learning rate, batch size, and epochs, beyond the per-argument documentation all functions already carry.
- Testing (General standards, sub-category 5.x): 811 passing tests (0 failures) with ~92% coverage; correctness tests against an independent reference implementation (
stats::lm()) under fixed seeds and explicit tolerances; noise-susceptibility and algorithm-performance tests (behaviour under trivial input perturbation, under different random seeds, and under an early-stopping threshold); the standard edge-condition battery (zero-length data, unsupported types, all-NA columns, more columns than rows); a dedicated test file exercising every error, warning, and informational message the package can emit, with the gap list derived mechanically from coverage analysis rather than by inspection; and an environment-variable-gated extended suite for multi-seed parameter-recovery testing, documented in tests/README.md.
We are not claiming gold: reaching it requires reviewers to independently confirm that no additional standards beyond our own @srrstatsNA list are applicable, plus at least three of the four aspects above — including the internal-design aspect, which the guide states is "ultimately determined by reviewers" rather than something authors can self-assess. We would welcome reviewers elevating the badge to gold if they judge it warranted, as the guide explicitly allows post-review.
Technical checks
Confirm each of the following by checking the box.
Note on autotest::autotest_package():
autotest_package() surfaced one real bug in kindling, which is fixed: grid_depth() crashed with an uninformative seq() error ('from' must be a finite number) when given an unfinalized {dials} parameter; it now raises an informative error instead (joshuamarie/kindling#40).
A full autotest_package() run does not currently complete against this package, but the remaining failure is not in kindling — it's in autotest's typetracer dependency (github mpadge/typetracer, dev version 0.2.4.002). Its test-instrumentation code crashes on ordinary testthat conventions: it does a non-fixed grep() of a literal test description (breaking on any description containing (), e.g. "foo() does X"), mislocates test bodies' opening braces when a description contains a literal {pkgname}, and (once those are worked around) its own tracer errors out and breaks S3 dispatch for a {vip}-provided generic while instrumenting kindling's functions. None of this reproduces when running kindling's test suite directly, bypassing autotest/typetracer (0 failures). The typetracer maintainer (@mpadge) asked me to re-test against the latest GitHub version; I did (commit 617dae2, current main HEAD) and the failure is unchanged. Filed upstream: mpadge/typetracer#29.
Happy to re-run autotest_package() for review once these are fixed upstream, or to walk through the investigation in more detail if useful.
This package:
Use of Generative AI
Generative AI (Claude/Claude Code, Anthropic) was used in two ways: (1) to suggest English phrasing and improve clarity, with all content critically reviewed and finalized by the authors; and (2) to run an automated pre-submission audit of the package (build, tests, documentation, README reproducibility) prior to the submission, with all findings reviewed and acted on by the authors.
Publication options
Code of conduct
Submitting Author Name: Antoine Soetewey
Submitting Author Github Handle: @AntoineSoetewey
Other Package Authors Github handles: @joshuamarie
Repository: https://github.com/joshuamarie/kindling
Version submitted: v0.3.2
Submission type: Stats
Badge grade: silver
Editor: TBD
Reviewers: TBD
Archive: TBD
Version accepted: TBD
Language: en<!--end-language--
Scope
Please indicate which of our statistical package categories this package falls under. (Please check one or more appropriate boxes below):
Statistical Packages
Pre-submission Inquiry
General Information
R users already working in the
tidymodelsecosystem (researchers, applied statisticians, data scientists, students) who want to fit and tune feedforward or recurrent neural networks without hand-writingtorchmodel/training-loop code, while still being able to inspect, modify, or extend the generatedtorchcode directly. Applications include predictive modeling on tabular and sequential data, teaching neural-network fundamentals with inspectable generated code, and research workflows that needtidymodels-standard resampling/tuning/evaluation applied to deep learning models.kindling falls under the third category:
An improvement on other implementations of similar algorithms in R.
The underlying algorithms — feedforward neural networks (MLP/DNN/FFNN) and recurrent variants (RNN, LSTM, GRU) — are well established and are not novel; kindling does not implement them from scratch either, but builds directly on
{torch}'s tensor and autograd engine, itself R's binding to the LibTorch/PyTorch C++ backend. Nor is kindling the first R interface to torch-based neural networks: several higher-level packages already fill that role, most notably{brulee}(tidymodels' own torch engine, now covering MLPs, linear/logistic/multinomial regression, and several tabular deep-learning architectures — ResNet, SAINT, TabICL, AutoInt — plus a pretrained forecasting wrapper),{cito}(focused on explainability and statistical inference, with fully-connected and convolutional architectures), and{luz}(a general training-loop abstraction over arbitrary, user-authored torch modules). Earlier, pre-torch neural network implementations in R include base R'snnetand{neuralnet}.kindling's contribution relative to these is in interface design, not algorithmic novelty:
nn_module_generator()(and the higher-levelffnn_generator()/rnn_generator()) return the actualtorch::nn_module()expression as an object a user can print, modify, and re-evaluate before training. By contrast, brulee and cito construct theirnn_module()s internally inside their fitting functions (e.g. brulee'smlp_moduleis defined once, package-side, and instantiated insidemlp_fit_imp(); cito'sbuild_model()does the equivalent), with no inspectable intermediate step; luz takes the opposite approach and requires users to author thenn_modulethemselves, providing no generation at all.rnn()/rnn_generator()/rnn_kindling()supporting RNN, LSTM, and GRU cells with a configuration surface shared with the feedforward path (hidden_neurons, layer-specificactivations,nn_arch()for custom layer types). None of brulee, cito, or luz ship a built-in recurrent layer.{tidymodels}integration for recurrent models specifically, via a dedicatedparsnipengine (rnn_kindling()) with fulldials/tunehyperparameter-tuning support — an architecture family none of the compared packages expose through tidymodels at all.Not applicable:
kindlingis a general-purpose modeling framework that does not collect, store, or process personal, sensitive, or human-subjects data itself; any data privacy considerations depend entirely on what data a user chooses to train on.Badging
We are targeting silver. kindling fulfils at least two of the four aspects listed for silver:
1. Compliance with a good number of standards beyond the minimal set. Every General and ML standard we identify as applicable is met: 56/56 applicable General standards and 60/60 applicable ML standards (100%), with the remaining 12 General and 30 ML standards tagged
@srrstatsNAand individually justified — none left as@srrstatsTODO. Counting allgeneral+mlstandards together (158 total, including the justified-NA ones), that is 116/158 = 73.4% overall compliance, comfortably above the "more than one half" bar for this aspect.srr::srr_stats_pre_submit()confirms the package as fully documented against the current standards, and the automated check on the pre-submission thread independently reports the same figures.2. Excellence in at least two broad sub-categories — specifically documentation and testing, which is the guide's own illustrative example for this aspect:
{brulee},{cito},{luz}) and a worked demonstration that a zero-hidden-layer network recovers OLS/logistic regression as a special case;?train_nncarries dedicated sections on training/validation/test data semantics, the missing-value policy (with a runnable{recipes}imputation example), and guidance on learning rate, batch size, and epochs, beyond the per-argument documentation all functions already carry.stats::lm()) under fixed seeds and explicit tolerances; noise-susceptibility and algorithm-performance tests (behaviour under trivial input perturbation, under different random seeds, and under an early-stopping threshold); the standard edge-condition battery (zero-length data, unsupported types, all-NAcolumns, more columns than rows); a dedicated test file exercising every error, warning, and informational message the package can emit, with the gap list derived mechanically from coverage analysis rather than by inspection; and an environment-variable-gated extended suite for multi-seed parameter-recovery testing, documented intests/README.md.We are not claiming gold: reaching it requires reviewers to independently confirm that no additional standards beyond our own
@srrstatsNAlist are applicable, plus at least three of the four aspects above — including the internal-design aspect, which the guide states is "ultimately determined by reviewers" rather than something authors can self-assess. We would welcome reviewers elevating the badge to gold if they judge it warranted, as the guide explicitly allows post-review.Technical checks
Confirm each of the following by checking the box.
autotestchecks on the package, and ensured no tests fail.srr_stats_pre_submit()function confirms this package may be submitted.pkgcheck()function confirms this package may be submitted - alternatively, please explain reasons for any checks which your package is unable to pass.Note on
autotest::autotest_package():autotest_package()surfaced one real bug in kindling, which is fixed:grid_depth()crashed with an uninformativeseq()error ('from' must be a finite number) when given an unfinalized{dials}parameter; it now raises an informative error instead (joshuamarie/kindling#40).A full
autotest_package()run does not currently complete against this package, but the remaining failure is not in kindling — it's inautotest'stypetracerdependency (github mpadge/typetracer, dev version 0.2.4.002). Its test-instrumentation code crashes on ordinarytestthatconventions: it does a non-fixedgrep()of a literal test description (breaking on any description containing(), e.g."foo() does X"), mislocates test bodies' opening braces when a description contains a literal{pkgname}, and (once those are worked around) its own tracer errors out and breaks S3 dispatch for a{vip}-provided generic while instrumenting kindling's functions. None of this reproduces when running kindling's test suite directly, bypassingautotest/typetracer(0 failures). The typetracer maintainer (@mpadge) asked me to re-test against the latest GitHub version; I did (commit 617dae2, current main HEAD) and the failure is unchanged. Filed upstream: mpadge/typetracer#29.Happy to re-run
autotest_package()for review once these are fixed upstream, or to walk through the investigation in more detail if useful.This package:
Use of Generative AI
Generative AI (Claude/Claude Code, Anthropic) was used in two ways: (1) to suggest English phrasing and improve clarity, with all content critically reviewed and finalized by the authors; and (2) to run an automated pre-submission audit of the package (build, tests, documentation, README reproducibility) prior to the submission, with all findings reviewed and acted on by the authors.
Publication options
Code of conduct