Add keyword arguments to spectrogram

[v923z]

Details and rationale are outlined in https://github.com/v923z/micropython-ulab/blob/spectrum/docs/ulab-utils.ipynb, but the gist is that spectrogram now allows for the re-use of allocated memory (through the out, and scratchpad keyword arguments), as well as direct calculation of the logarithm (through the log keyword argument).

from ulab import numpy as np
from ulab import utils as utils

n = 1024
t = np.linspace(0, 2 * np.pi, num=1024)

scratchpad = np.zeros(2 * n) # re-usable RAM for the calculation of the FFT

for _ in range(10):
    signal = np.sin(t)  # this simulates a measurement of some signal
    utils.spectrogram(signal, out=signal, scratchpad=scratchpad, log=True)

@jepler, @dhalbert this might be relevant for circuitpython users.

[brainstorm]

this might be relevant for circuitpython users.

And for micropython ones too! I was looking for that log component (because of an audio application I'm working on). Plus that RAM-saving scratchpad feature is a good addition too.

Please get this merged! ;)

[v923z]

Please get this merged! ;)

If you have any comments on the concept itself, please, let me know! This is the best I could come up with, but that doesn't mean that this is the best.

[brainstorm]

Please get this merged! ;)

If you have any comments on the concept itself, please, let me know! This is the best I could come up with, but that doesn't mean that this is the best.

Sure, fair enough. I just built a runtime with this for esp32s3, tested it and some -inf values returned from my data stream surprised me but they make sense (and they are easily filterable w/ conditionals)... also the kwargs make sense to not break backwards compat. Other than that, LGTM... for sure I'd focus a bit more on improving perf as much as possible before merging since any optimization can save a ton of time at scale.

I'll keep playing with it this and next week and I'll let you know if anything else arises.

[brainstorm]

There was a minor conflict when merging with master btw, could you please rebase this PR and see if CI complains?

[v923z]

There was a minor conflict when merging with master btw, could you please rebase this PR and see if CI complains?

The actual conflict is just the version number of ulab, which is trivial. The other one from the CI is mentioned here: #669. Basically, for whatever reason, the executable on linux and on mac doesn't produce the exact same results in a couple of test cases.

There are two possible solutions to this: we either modify the tests in such a way that the difference disappears, or I add the precision keyword argument to set_printoptions https://numpy.org/doc/stable/reference/generated/numpy.set_printoptions.html#numpy-set-printoptions, and simply set the precision to a number, where the rounding errors disappear.

I would prefer the second solution, because it's cleaner, doesn't sweep anything under the rug, and adds a potentially useful feature. I'll just have to find out, how much it costs, although, I believe, it shouldn't be more than 200-300 bytes.