Add trig functions

[astewart-xmos]

Currently this library doesn't have offer any trig functions. It should. Including

• sin
• cos
• arctan
• arctan2 (with hypotenuse)
• arcsin
• arccos
• sinh
• cosh
• exp
• log

[mbanth]

Some of the tests in the Avona repository use sin and sinh functions from lib_dsp. If these become available in lib_xs3_math, we can reduce the dependency of the Avona reporistory on lib_dsp.

[astewart-xmos]

Per Michael's comment, in lib_dsp: declarations and definitions

[astewart-xmos]

Commit 7faf96f also contains a fix (no associated GitHub issue) for the random number generation used by the unit tests.

Previously, the tests were using a custom function for pseudo-random number generation. (I'm not sure where I got it.) But I noticed that there were relatively short-period cycles happening in the sequence of random numbers being generated. In practice, this meant that even if a test case was looping 1000 times to try different vectors, many of those repetitions would have been total duplicates of previous repetitions.

Now the C standard library's random() function is used.

One consequence of this is that there is now a wider variety of data being used in the random test cases. Many (read: almost all) of the unit test error thresholds were not set according to some theoretical maximum error, but rather through observing the actual error, reasoning about whether it is acceptable, and then setting the threshold to the maximum observed error. Then, with the wider variety of test vectors, a few tests here and there started seeing bigger maximum errors (in all but 1 case it only increased by 1 least significant bit). The previous two commits fix those tests.

[astewart-xmos]

Commit 36a125f also contains a fix for bfp_fft_inverse_stereo().

At least, I believe it's a fix for an issue that can arise in a narrow corner case. It was observed using the reference (C) implementation but I haven't directly observed it on the XS3 implementation.

Basically, xs3_fft_dit_inverse() requires two bits of headroom. That's because under narrow conditions, with the right spectrum, having less than two bits of headroom can lead to arithmetic saturation. bfp_fft_inverse_stereo() was ensuring 2 bits of headroom, but it did it prior to calling xs3_fft_spectra_merge(). Under the right conditions xs3_fft_spectra_merge() can also reduce the headroom.

In the case I was debugging, that seemed to be what was happening. xs3_fft_spectra_merge() was reducing headroom to 1 bit, and then saturation was occurring in xs3_fft_dit_inverse().

The symptom that ultimately helped me figure out what was going on was that the difference (as in, subtraction) between our C reference implementation (Block floating point) and the fully floating-point FFT implementation that we test against appeared to be an FFT_N-13-period sinusoid modulated by a 13-period sinusoid. Such a situation is indicative of saturation occurring on a particular frequency bin in the frequency domain.

I had two options for solving this: A) I could increase the headroom ensured by bfp_fft_inverse_stereo() from 2 to 3, or B) Check the headroom after merging spectra (xs3_fft_spectra_merge() returns the headroom) and if it's under 2, make the appropriate adjustment.

I opted for solution A), because we're only talking about 3 LSb's, and because solution B) would mean the IFFT is not (approximately) constant time (data dependence).

[astewart-xmos]

I have implemented sin, cos, tan, exp, log and also a logistic function (i.e. a sigmoid; based on exp rather than tanh). All have scalar implementations (some float, some float_s32_t, some fixed-point) and several (e.g. log, exp) also have vectorized implementations.

I have not yet implemented arcsin, arccos, arctan, sinh or cosh.