Comparison

numx vs the Alternatives

Different tools solve different problems. numx does not replace CMSIS-DSP for hardware-optimized Cortex-M DSP. It does not replace kiss_fft for someone who only needs a simple FFT. Here is what each library is optimized for, so you can pick the one that fits.

Feature	numx	CMSIS-DSP	kiss_fft	ESP-DSP	libm
Platform coverage	Any C99 target	Cortex-M / Cortex-A	Any C target	ESP32 only	Any C target
Zero dependencies	Yes	Requires CMSIS headers	Yes	ESP-IDF	C stdlib
Zero dynamic allocation	Yes	Yes	Yes	Yes	No
Reentrant / ISR-safe	Yes	Mostly	Yes	Varies	No
FFT	Yes (f32 + Q15)	Yes (many types)	Yes (f32)	Yes (optimized)	No
Signal processing	Yes	Yes	No	Yes	No
ODE solvers	Yes	No	No	No	No
Linear algebra	Yes	Partial	No	No	No
Automatic differentiation	Yes	No	No	No	No
Compressed sensing	Yes	No	No	No	No
Statistics	Yes	Partial	No	No	No
Root finding	Yes	No	No	No	No
Integration / diff	Yes	No	No	No	No
Hardware SIMD (Helium, Neon)	No	Yes	No	Yes	-
Typed status codes	Yes	Partial	No	No	No
License	MIT	Apache 2.0	BSD	Apache 2.0	Various

When to choose numx

+ Project spans multiple platforms (ESP32, ARM, x86-64) and you want one library across all of them
+ You need algorithms beyond DSP: ODE solvers, autodiff, compressed sensing, interpolation, root finding
+ Targeting RISC-V, AVR, or ESP32 where CMSIS-DSP is not available
+ You need full reentrancy guarantees (ISR + RTOS + multicore)
+ You want typed error codes on every function call

When to choose CMSIS-DSP

+ Exclusively targeting Cortex-M or Cortex-A and need hardware-accelerated SIMD (Helium, Neon)
+ You need data types numx does not currently support: q7, q31, float16
+ Already in the CMSIS ecosystem

When to choose kiss_fft

+ You only need FFT and want minimal code with a well-established library
+ On a platform with no numx validation data