Question/Issue:
The log() function provided in the SDK headers (numpy.hpp) is mathematically flawed on the Portenta H7 (ARM Cortex-M7) platform, leading to incorrect feature vector generation.
Context/Use case:
This issue is encountered when running any deployed impulse that utilizes an MFE block (and likely all other DSP blocks with logarithm-dependent feature scaling) on a Portenta H7. The local inference results do not match the expected results from the Studio.
Summary:
The inline function “static inline float log(float a)” in numpy.hpp uses a Bit-Manipulation/Type-Punning optimization hack that violates the C++ Strict Aliasing Rule. On the Portenta H7 platform, this leads to mathematically wrong logarithm values. This core mathematical error corrupts subsequent DSP feature vectors.
Steps to Reproduce:
- Deploy any impulse containing an audio DSP block (MFE) as a C++ Library.
- Implement the inference code on a Portenta H7
- Compare the resulting feature vector (output of the DSP block) with the expected vector from the Studio.
Minimal Reproducible Example (isolates the bug)
Run this code on a Arduino Portenta H7:
printf(“log(2.7)=%f\r\n”, numpy::log(2.7));
Expected Results:
log(2.7)=0.993252 (The natural logarithm of 2.7)
Actual Results:
log(2.7)=3.386294 (An incorrect value)
Reproducibility:
- [x] Always
Environment:
- Platform: Portenta H7 (STM32H7)
- Build Environment Details: GCC/CubeIDE 1.19.0 with optimization -O0
- OS Version: Windows 10
- Edge Impulse Version (Firmware): 1.77.1