Signatory: differentiable computations of the signature and logsignature transforms, on both CPU and GPU

1 INTRODUCTION

• The signature captures order, area, and cross-channel interactions, unlike the linear, channel-wise Fourier transform.It is described as universally nonlinear (Bonnier et al., 2019, Proposition A.6).Source: §1 · p. 1
• Embedding these transforms in neural networks requires efficient repeated evaluation, whereas previous libraries were CPU-only and single-threaded bottlenecks.The transforms are evaluated many times during training and evaluation.Source: §1 · p. 1

1.1 CONTRIBUTIONS

• Signatory is a CPU- and GPU-capable, differentiable library for signature and logsignature transforms focused on machine learning.It integrates with PyTorch and provides tensor operations suitable for neural-network workflows.Source: §1.1 · p. 2
• Novel algorithmic improvements and parallelism make Signatory significantly faster than previous libraries on both CPU and GPU.The improvements include uniform and asymptotic rate gains.Source: §1.1 · p. 2
• Signatory adds efficient precomputation strategies for querying signatures and logsignatures over arbitrary overlapping intervals.This functionality was unavailable in previous libraries.Source: §1.1 · p. 2

2.1 THE SIGNATURE TRANSFORM

• The signature maps a sequence to iterated tensor information, computed through tensor products and Chen’s group-like composition law.For piecewise affine paths, the signature can be decomposed into exponentials of successive increments.Source: §2.1 · p. 2, §2.2 · p. 3

2.3 THE LOGSIGNATURE, INVERTED SIGNATURE, AND INVERTED LOGSIGNATURE

• The inverted signature and logsignature transforms are defined using group inversion and logarithms, but are not inverse maps of the corresponding forward transforms.The paper explicitly distinguishes these operations from mathematical inverse maps.Source: §2.3 · pp. 3–4
• The logsignature represents the same information as the signature in a more compact proper subspace of the truncated tensor space.Its dimension is characterized using Witt’s formula.Source: §2.3 · p. 4

2.4 SIGNATURES IN MACHINE LEARNING

• Signature, logsignature, and inverted transforms consume sequence tensors of shape (b, L, d), producing signature features of size (b, Σ_{k=1}^N d^k) or logsignature features of size (b, w(d, N)).These output representations can become large.Source: §2.4 · p. 4
• All provided transforms are differentiable with respect to the input sequence and can therefore be backpropagated through as machine-learning tensor operations.They can function as binning functions, feature extractors, or nonlinearities that summarize sequential data.Source: §2.4 · p. 4, §2.5 · p. 4

3 CODE EXAMPLE

• Signatory computes the path signature at the requested depth and returns a PyTorch-compatible tensor.The library is designed to expose operations like ordinary PyTorch operations.Source: §3 · pp. 4–5
• The example creates a random path tensor with batch size 1, stream length 10, 2 channels, and depth 4.The path is created with requires_grad=True.Source: §3 · pp. 4–5
• The example calls backward on the summed signature, demonstrating differentiation through the signature transform.The input path was configured to require gradients.Source: §3 · p. 5

4.1 FUSED MULTIPLY-EXPONENTIATE

• The fused operation A ⊠ exp(z) reduces complexity from O(Nd^N) to O(d^N), achieving the optimal rate for its O(d^N)-sized output.It also uses uniformly fewer scalar multiplications than composing the separate exponential and ⊠ operations.Source: §4.1 · p. 5
• Expressing most signature computation through the fused operation yields substantial real-world speedups, with one initial exponential followed by a noncommutative reduction.The reduction exploits the associative ⊠ operation and is benchmarked in Section 6.Source: §4.1 · p. 5

4.2 IMPROVED PRECOMPUTATION STRATEGIES

• Arbitrary interval signature queries take O(1) time and memory after O(L) precomputation and storage, improving on prior O(log L) inference with O(L log L) precomputation.Prefix signatures and inverted prefix signatures are combined using the group-like structure; large i, j may introduce numerical stability issues.Source: §4.2 · p. 5

4.3 MORE EFFICIENT LOGSIGNATURE BASIS

• The proposed logsignature basis is computationally cheaper than the Lyndon basis because each new basis element contains exactly one Lyndon word after expansion.Its coefficient can therefore be obtained directly from the corresponding tensor-algebra coefficient, and the basis choice is mostly unimportant before a learned linear map.Source: §4.3 · p. 6

5 NEW FEATURES

• CPU execution uses OpenMP and parallel associative reductions, while C++ primitives are bound into PyTorch for the necessary operations.The reduction parallelizes by splitting the fused multiply-exponentiate computation into chunks.Source: §5.1 · p. 6
• Signatory supports GPU execution through LibTorch and full backpropagation through every provided operation, unlike prior limited support through only simple operations.GPU execution also avoids transferring data between GPU and CPU when signatures are embedded in GPU-trained models.Source: §5.2 · p. 6, §5.3 · p. 6
• Signatory provides inverse signatures, multi-interval computation, interval combination, expanding-interval computation, and streaming updates to reduce unnecessary recomputation.Expanding intervals require only O(L) work, with earlier signatures available as byproducts of computing the final signature.Source: §5.4 · p. 6, §5.5 · p. 7
• The Path class exposes efficient precomputation for querying signatures over arbitrary overlapping intervals.The strategy supports many interval queries from one sequence using the precomputation described in Section 4.2.Source: §5.5 · p. 7

6 BENCHMARK PERFORMANCE

• The benchmarks compared esig and iisignature on CPU with Signatory on GPU, parallel CPU, and nonparallel CPU, emphasizing like-for-like CPU and best-performance GPU comparisons.Each test case was repeated 50 times, and the fastest time was recorded.Source: §6 · p. 7, §6.1 · p. 8

6.1 DIRECT COMPARISON

• Signatory and iisignature were comparable on the smallest forward computations, after which Signatory’s CPU implementations overtook iisignature and its GPU implementation followed.The benchmark varied channels from 2–7 and depth from 2–9 for batches of 32 sequences of length 128.Source: §6.1 · p. 8
• 132× speedup was obtained for a depth-7, seven-channel signature on Signatory’s GPU versus iisignature.The corresponding times were 0.16 seconds for Signatory on GPU and 20.9 seconds for iisignature.Source: §6.1 · pp. 8–9
• 166× and 9.4× speedups were obtained for backward computation on Signatory’s GPU and CPU without parallelism, respectively.For depth and channel count both equal to 7, iisignature took 128 seconds, compared with 0.772 seconds on Signatory’s GPU and 13.7 seconds on its like-for-like CPU.Source: §6.1 · p. 9

6.2 DEEP LEARNING EXAMPLE

• 210× faster training was achieved by the Signatory-based deep signature model than by the iisignature-based model.Both models trained successfully; the authors attribute the larger improvement partly to iisignature copying data between GPU and CPU.Source: §6.2 · p. 9

7 CONCLUSION

• Signatory is a CPU- and GPU-capable library whose operations are differentiable and whose contributions include novel algorithmic innovations.The library targets machine-learning applications involving signature and logsignature transforms.Source: §7 · p. 9

A.1 FUSED MULTIPLY-EXPONENTIATE

• The conventional signature computation iterates by exponentiating each increment and combining it with the accumulated result, whereas the proposed method fuses those operations.The fused operation is then applied iteratively.Source: §A.1 · p. 12
• Signatory’s fused multiply-exponentiate uses fewer multiplications than the conventional method for all d ≥1 and N ≥1, with lower asymptotic complexity.The analysis establishes a uniform bound and contrasts F(d, N) = O(dN) with C(d, N) = Ω(NdN).Source: §A.1 · p. 12, §A.1.3 · p. 14

A.1.1 THE CONVENTIONAL WAY

• The conventional computation lacks a formal lower-bound analysis for ⊠, and no better computation method than following its definition naively is known to the authors.This qualifies the analysis of the conventional method rather than establishing an optimality result.Source: §A.1.1 · p. 13

A.2.3 BASES FOR LOGSIGNATURES

• The Lyndon-basis system is overdetermined but has a unique solution because image(log) equals image(φ).The overdetermined representation captures the same information in less space than the signature transform.Source: §A.2.3 · p. 16
• Signatory uses triangularity to define an invertible change of basis, avoiding the unnecessarily expensive direct Lyndon-basis solve.This alternate basis is appropriate when a subsequent learned linear transformation makes the specific logsignature basis less important.Source: §A.2.3 · pp. 16–17

IMPLEMENTATION

• Handwritten backpropagation uses C++ primitives and exploits signature reversibility to recover intermediate signatures instead of storing them all.Intermediate results are reconstructed from the final signature by repeatedly applying the inverse combination relation.Source: C BACKPROPAGATION · p. 17, §C.1 · p. 17

C.2 SPEED VERSUS MEMORY TRADE-OFFS

• Signatory does not offer an alternative that stores multiple partially computed signatures, despite their potential memory relevance for long or high-frequency data.The paper identifies this as an opportunity for further work.Source: §C.2 · p. 18

C.3 PARALLELISM

• Parallel backward computation is possible when all intermediate forward results are held in memory, because the signature computation forms a balanced tree.This is the alternative to Signatory’s reversible memory-saving strategy.Source: §C.3 · p. 18
• Signatory does not perform backpropagation in parallel because reversibility retains only the final signature and omits the intermediate results needed for parallel execution.Without reversibility, the balanced-tree forward computation graph would support parallel backward computation.Source: §C.3 · p. 18
• The paper expects the impact of omitted backward parallelism to be moderate because batch and primitive-operation parallelism may already saturate available parallelism.The statement is presented as an expectation rather than a benchmarked conclusion.Source: §C.3 · p. 18

• Memory usage was sampled at intervals with memory_profiler instead of Valgrind’s massif.The alternative method avoids setup-measurement difficulties but can miss memory peaks.Source: §D.2 · p. 19
• The benchmark values were considered unreliable for quantitative reporting because sampling may miss peaks and differs from earlier results.Source: §D.2 · p. 19
• An order of magnitude less memory was typically used by Signatory than iisignature on larger computations.Larger calculations make missed peaks less likely, but the authors do not report quantitative memory benchmarks.Source: §D.2 · p. 19

• The benchmarks reported forward and backward logsignature timings across varying channels and depths, with numerical values in Tables 5–8.A dash indicates that esig does not support an operation.Source: §D.4 · p. 19
• Signatory became orders of magnitude faster than iisignature as logsignature computations grew larger.Source: §D.4 · p. 19
• iisignature was slightly faster for some very small logsignature computations, before Signatory overtook it on larger problems.Source: §D.4 · p. 19

• The single-element-batch evaluation repeated forward and backward signature and logsignature benchmarks while varying depth and channels.Numerical values were presented in Tables 9–16.Source: §D.5 · p. 19
• Signatory was orders of magnitude faster than iisignature on larger single-element-batch problems.Source: §D.5 · p. 20
• iisignature outperformed Signatory by about a millisecond on very small single-element-batch problems, but Signatory overtook it as problem size increased.Source: §D.5 · p. 20
• Very small single-element-batch performance was not regarded as a drawback because many small calculations can typically be batched together.Source: §D.5 · p. 20
• The benchmark figures used logarithmic time scales, fixed sequence length 128, and repeated each test 50 times while recording the fastest time.For varying channels, depth was fixed at 7; for varying depths, channels was fixed at 4.Source: Figure 5 · p. 23, Figure 6 · p. 24