Pith. sign in

REVIEW 2 major objections 5 minor 11 references

kindling: A Higher-Level torch Interface for Generating, Training, and Tuning Neural Networks in R

T0 review · 2 major / 5 minor · reviewed 2026-07-11 · grok-4.5

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read kindling is an R package that reduces torch boilerplate by generating inspectable neural-network code, training from formulas, and registering models for hyperparameter search inside existing tidymodels workflows.

desk verdict Solid software-announcement paper for a real R package that combines inspectable torch code generation with full tidymodels tuning; modest niche value, ordinary youth caveats, no hidden flaws. read the letter →

arxiv 2607.03832 v1 pith:GAHMTHNP submitted 2026-07-04 stat.CO

Antoine Soetewey (1) , Joshua Marie (2) ((1) HEC Liège , Université de Liège , Rue Louvrex 14 , 4000 Liège , Belgium , (2) Independent Researcher) This is my paper · ORCID
classification stat.CO
keywords neuralnetworksRpackagetorchtidymodelsmultilayerperceptronrecurrentcodegenerationhyperparametertuning
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper presents kindling, an R package that sits above torch so analysts can define, train, and tune multilayer perceptrons and recurrent networks without writing model classes and training loops by hand. At the lowest level, generator functions return unevaluated torch module expressions that can be printed, edited, or run outside the package rather than treated as opaque wrappers. At the middle level, formula-based training functions prepare data, run the optimization loop, and optionally apply early stopping and a validation split. At the top level, registered model specifications let the same architectures be fit, tuned, and evaluated with the preprocessing, workflow, and search tools already used for other model types. The design is meant to let users move from exploratory fits to systematic search over depth, widths, activations, and optimizers without leaving their usual modeling stack or losing the ability to audit the generated network code.

What carries the argument

The three-level API built on metaprogramming code generation: functions that emit quoted nn_module expressions; direct formula trainers that reuse hardhat mold/forge for data handling; and dials-registered parameters (hidden widths, depth, activations, output activation, optimizer) that plug into ordinary tune grids.

What would settle it

Take a standard classification data frame and try the documented path: generate an inspectable module expression, fit via the formula interface, register the model as a specification, and run a tune grid over hidden widths and activations; if the generated code is opaque, the model cannot enter the search machinery, or a custom training loop is still required, the central claim fails.

Watch

Extended reading notes

Core claim

kindling claims that separating code generation from execution—returning inspectable unevaluated torch module expressions, then wrapping them in formula training and registered model specifications—lets multilayer perceptrons and recurrent architectures (RNN, LSTM, GRU) sit inside standard R modeling and tuning workflows instead of beside them as black boxes.

Load-bearing premise

That this three-level design is complete and stable enough for real modeling workflows even though the package is young and its most general generator and training interface is still experimental.

Editorial extensions

If this is right

  • An analyst can point an existing resampling and tune-grid workflow at a neural network by changing only the model specification.
  • Generated module code can be inspected, copied, hand-edited, and executed outside the package for teaching or small custom changes.
  • Layer widths, network depth, activation choices, and related architectural knobs become searchable dimensions rather than fixed manual settings.
  • Recurrent architectures become available through the same formula and tuning path as feedforward networks.
  • Fitted models can be scored with standard variable-importance tools without a separate explainability pipeline.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Inspectable generated modules may make deep-learning demos more usable in statistical computing courses that want students to read the network definition, not only call fit.
  • If the experimental general generator matures, the same pattern could cover other sequential architectures without a new high-level entry point for each family.
  • Long-term usability will depend on whether the tunable parameter objects stay stable as the architecture-specific entry points are consolidated.
  • Early download and repository activity show community readiness, but sustained production use will test whether the three levels stay consistent under version change.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

2 major / 5 minor

Summary. The manuscript presents kindling, an R package that supplies a three-level interface to torch for multilayer perceptrons and recurrent networks (RNN, LSTM, GRU). Generator functions return inspectable, unevaluated torch::nn_module() expressions; intermediate helpers (ffnn, rnn) train from a formula and data frame with optional early stopping and validation; and parsnip-registered specifications (mlp_kindling, rnn_kindling) expose the same models to tidymodels workflows, recipes, and dials/tune hyperparameter search. The design goal is to reduce torch boilerplate while keeping generated code auditable and allowing users to move from exploratory fits to systematic tuning without leaving the tidymodels ecosystem. Positioning against brulee, cito, and luz, plus CRAN release history, test coverage, and a concrete iris/garson example, constitute the supporting evidence.

Significance. If the claimed integration holds, kindling fills a practical gap for applied R users who want neural nets inside existing tidymodels pipelines rather than as a separate torch workflow. The inspectable code-generation layer is a genuine differentiator relative to opaque wrappers and is useful for teaching and light customization. Strengths that should be credited include the explicit three-level API, hardhat-based preprocessing, dials-registered parameters, the act_funs eDSL, CRAN availability (0.1.0–0.3.1), 206 testthat blocks under continuous R-CMD-check, and clear positioning against related packages. For a software-announcement paper in stat.CO these are appropriate forms of evidence; the contribution is engineering completeness rather than a new statistical method.

major comments (2)
  1. Software design section: the authors note that ffnn()/rnn() bypass the experimental S3 train_nn() dispatch and that the generalized nn_module_generator/train_nn interface remains experimental. Because the central claim is that the three-level design is ready for production tidymodels workflows, the manuscript should either (a) document the supported surface as stable and mark the experimental path clearly, or (b) provide a short consolidation roadmap so readers know which entry points are intended for long-term use. This is a load-bearing maturity issue for the production-readiness claim, not a cosmetic one.
  2. State of the field / Research impact: the comparison with brulee asserts that kindling is 'just as production-ready' while offering broader architecture support and inspectable code. The manuscript supplies design arguments and test counts but no side-by-side workflow example (e.g., identical tune_grid call on the same recipe/workflow for brulee vs. kindling) or minimal performance/robustness check. A single concrete, reproducible comparison would make the production-readiness claim falsifiable rather than rhetorical.
minor comments (5)
  1. Figure 1 caption and surrounding text: the long one-line call is hard to parse; consider a multi-line code block or a short vignette excerpt so readers can reproduce the garson plot without retyping.
  2. Summary and Statement of need: a few typographic artifacts remain (e.g., 'HEC Li` ege', 'Universit´ e', 'mlp kindling' vs. mlp_kindling). Normalize package and function names to consistent monospaced or braced form throughout.
  3. Software design: the act_funs() eDSL is described as 'akin to dplyr::pick()'; a one-line example of a parametric activation (softshrink[lambd=0.5]) already appears in the figure caption—move a minimal self-contained snippet into the main text for readers who skip the figure.
  4. Research impact statement: download and star counts are useful community-readiness signals but age quickly; state the snapshot date explicitly (already July 2026) and consider adding a short note that they are not performance claims.
  5. References: ensure package version pins (torch 0.16.3, parsnip 1.6.0, etc.) match the CRAN versions cited and that arXiv preprints (cito) are updated if journal versions exist.

Circularity Check

0 steps flagged · score 0.0 of 10

No circular derivation: software-design announcement with no fitted predictions or self-justifying uniqueness claims.

full rationale

This is a JOSS-style software paper announcing the kindling R package. Its central claim is an engineering one: three levels of abstraction (code-generation of inspectable unevaluated torch::nn_module() expressions, formula-based direct training, and parsnip/tidymodels engines with dials-tunable parameters) reduce torch boilerplate for MLPs and recurrent nets while remaining inspectable and integrable with existing workflows. The manuscript supports that claim with concrete design choices (metaprogramming generators, hardhat mold/forge, act_funs eDSL, dials parameter objects), explicit positioning against brulee/cito/luz, and community-readiness metrics (CRAN releases, download counts, stars, 206 testthat blocks). None of these steps is a scientific prediction derived from fitted constants, a uniqueness theorem imported from the authors, or a renaming of a known empirical pattern. Download/star/test counts are self-reported readiness evidence, not used to prove a result by construction. There is no derivation chain that reduces to its own inputs; residual package youth and experimental status of the generalized generator are maturation notes the authors themselves surface, not circularity. Score 0 is therefore the correct, proportionate finding.

Assumptions & free parameters 0 free parameters · 4 assumptions · 3 invented entities

Software paper; load-bearing premises are engineering and ecosystem assumptions rather than physical or mathematical axioms. No free parameters fitted to scientific data. Invented entities are package APIs, not postulated physical objects.

assumptions (4)
  • domain assumption torch provides correct tensors, autodiff, and nn_module semantics for the generated architectures
    Entire stack delegates execution to torch; correctness of training rests on torch (Falbel & Luraschi 2025).
  • domain assumption tidymodels/parsnip/dials/tune/hardhat conventions remain stable enough for registered engines to stay compatible
    Highest abstraction level is defined by registration into parsnip and dials parameter objects (Software design).
  • ad hoc to paper Metaprogramming that emits unevaluated nn_module expressions is preferable to opaque wrappers for auditability and teaching
    Central design decision stated in Software design; not forced by prior literature.
  • domain assumption hardhat::mold()/forge() correctly handle predictor roles, factor encoding, and missing data for neural-net inputs
    Preprocessing is delegated rather than reimplemented (Software design).
invented entities (3)
  • act_funs() eDSL with bracket syntax for parametric activations
    purpose: Provide call-like syntax for activation functions including parameters (e.g. softshrink[lambd=0.5]) and new_act_fn escape hatch
    Introduced in Software design as package-specific NSE interface; no independent existence outside kindling.
  • mlp_kindling / rnn_kindling parsnip model specifications and associated dials parameters (hidden_neurons, activations, grid_depth, etc.)
    purpose: Register neural nets as first-class tidymodels engines with tunable architecture dimensions
    Core package contribution; exists only as this software interface.
  • Experimental generalized nn_module_generator / train_nn S3 interface
    purpose: Extend code generation beyond fixed MLP/RNN families to arbitrary sequential torch architectures (e.g. 1-D CNNs)
    Marked experimental in State of the field / Software design; not yet a stable public contract.

how reviews work

0 comments
Cite this review

Pith. "Pith review of kindling: A Higher-Level torch Interface for Generating, Training, and Tuning Neural Networks in R." pith.science (2026). https://pith.science/paper/GAHMTHNP

@misc{pith2026260703832,
  author       = {Pith},
  title        = {Pith review of: kindling: A Higher-Level torch Interface for Generating, Training, and Tuning Neural Networks in R},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/GAHMTHNP}},
  note         = {Machine review of arXiv:2607.03832}
}
read the original abstract

{kindling} is an R package that provides a higher-level interface to {torch}, R's native implementation of PyTorch, for defining, training, and tuning neural networks. It supports multilayer perceptrons and recurrent architectures (RNN, LSTM, GRU) while reducing the boilerplate typically required to write {torch} model definitions and training loops by hand. The package is organized around three levels of abstraction: code-generation functions that return inspectable, unevaluated {torch::nn\_module()} expressions; direct-training functions that fit a model from a formula and data frame; and {tidymodels}-registered model specifications that let neural networks be fit, tuned, and evaluated using the {tune}, {dials}, {recipes}, and {workflows} infrastructure that {tidymodels} users already rely on for other model types. This design lets analysts move from exploratory training to systematic hyperparameter search without leaving the {tidymodels} ecosystem, while retaining the ability to inspect or modify the generated model code rather than treating it as a black box.

Figures

Figures reproduced from arXiv: 2607.03832 by the authors.

Figure 1
Figure 1. Garson’s algorithm variable-importance scores ( [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

11 extracted references · 2 canonical work pages

  1. [1]

    2025 , url =

    R: A Language and Environment for Statistical Computing , author =. 2025 , url =

    2025

  2. [2]

    2025 , note =

    torch: Tensors and Neural Networks with 'GPU' Acceleration , author =. 2025 , note =

    2025

  3. [3]

    , author =

    Tidymodels: a collection of packages for modeling and machine learning using tidyverse principles. , author =. 2020 , doi =

    2020

  4. [4]

    2026 , note =

    parsnip: A Common API to Modeling and Analysis Functions , author =. 2026 , note =

    2026

  5. [5]

    2026 , note =

    brulee: High-Level Modeling Functions with 'torch' , author =. 2026 , note =

    2026

  6. [6]

    arXiv preprint arXiv:2303.09599 , year =

    cito: An R package for training neural networks using torch , author =. arXiv preprint arXiv:2303.09599 , year =

    arXiv

  7. [7]

    2026 , note =

    luz: Higher Level 'API' for 'torch' , author =. 2026 , note =

    2026

  8. [8]

    mlr3: A modern object-oriented machine learning framework in R , volume =

    Lang, Michel and Binder, Martin and Richter, Jakob and Schratz, Patrick and Pfisterer, Florian and Coors, Stefan and Au, Quay and Casalicchio, Giuseppe and Kotthoff, Lars and Bischl, Bernd , year =. mlr3: A modern object-oriented machine learning framework in R , volume =. Journal of Open Source Software , publisher =. doi:10.21105/joss.01903 , number =

    doi:10.21105/joss.01903

Show all 11 references
  1. [9]

    , year =

    Beck, Marcus W. , year =. <b>NeuralNetTools</b>: Visualization and Analysis Tools for Neural Networks , volume =. Journal of Statistical Software , publisher =. doi:10.18637/jss.v085.i11 , number =

    doi

  2. [10]

    AI expert , volume=

    Interpreting neural-network connection weights , author=. AI expert , volume=. 1991 , publisher=

    1991

  3. [11]

    black box

    Olden, Julian D and Jackson, Donald A , year =. Illuminating the “black box”: a randomization approach for understanding variable contributions in artificial neural networks , volume =. Ecological Modelling , publisher =. doi:10.1016/s0304-3800(02)00064-9 , number =

    doi

Pith tools

Reviewed July 11, 2026 · model on record in the stance chip above.