TorchCurves aims to make learnable parametric curves a reusable component of machine-learning models. In an arXiv preprint posted November 10, 2026, Alex Shtoff presents a pure-PyTorch library whose benchmarks suggest that this flexibility can be computationally practical, particularly at larger workload sizes. The findings come from the library’s author, and peer review has not been verified.
The library converts batches of scalar inputs into points on vector-valued curves represented with B-splines or Legendre polynomials. It supports differentiation through both inputs and curve coefficients, allowing training to adjust the curves while passing gradients to earlier network layers. Coefficients can also come from another network. Trainable modules, reusable basis modules and a functional interface provide different ways to integrate these operations.
Its contribution is a common interface for composing curves, rather than a new curve representation. Code examples show continuous numerical features mapped to embedding vectors, construction of Kolmogorov–Arnold networks (KANs), and an auction-response model using nondecreasing spline coefficients. These examples demonstrate implementation possibilities; they do not establish downstream accuracy or business benefits.
For computation, TorchCurves uses vectorized Cox–de Boor and Clenshaw algorithms without custom hardware kernels. Operations are batched across samples and curves, although evaluation still loops over polynomial degree. The paper reports checking curve values against SciPy and NumPy and validating derivatives with PyTorch numerical gradient checks in float32 and float64. Error magnitudes and tolerances are not supplied.
The author compared CPU curve evaluation against SciPy splines and NumPy Legendre polynomials without backpropagation. Five timing measurements were summarized by medians for each configuration. The reported pattern was slower evaluation for small batches or few curves, with comparable or faster evaluation at larger scales. Exact speedups cannot be extracted because the supplied text lacks the numerical cells in the figures. The suggestion that PyTorch’s multicore execution explains the larger-workload advantage remains a conjecture.
A separate comparison measured KAN training-step times against EfficientKAN on CPU and GPU. After 50 warmup steps, the author took five measurements of 100 steps each, including gradient clearing, forward and backward passes, and optimizer updates. TorchCurves was described as broadly comparable, faster for larger batches and higher dimensions and slower otherwise. However, the implementations have different architectures and parameter counts. The paper also gives conflicting input widths: [16, W, W, 1] in the main text and [32, W, W, 1] in the figure caption.
All timings came from one Lenovo P14s Gen-7 laptop with an Intel Core Ultra 7 356H CPU and NVIDIA RTX PRO 500 Blackwell GPU; CPU execution was restricted to cores 1–4. Repeated timings on that machine are not independent hardware or dataset replications. Variability and confidence intervals are not reported, and the exact workload grids are unavailable in the supplied text. The results therefore describe performance in the tested configurations, not universal speed superiority, better predictions, faster convergence or less time to equivalent accuracy.
Source: https://arxiv.org/abs/2611.14516
Library: https://github.com/alexshtf/torchcurves
Cover illustration generated with AI; conceptual, not research evidence.