pfeatherstone

The boost implementation is unbelievably complicated. Sod it, would it be agreeable to add PRs for filter design and STFTs and have `__cpp_lib_math_special_functions` as a contract pre-condition?

Looked at scipy implementation, it's Fortran...

Not sure. Libc++ doesn't support special math functions so clang on macOS wouldn't work. Some compilers don't fully support std::filesystem which is c++17. So I don't think c++17 is universally...

I'll crack on with stripping boost but my god they needlessly make things complicated. Like every single function is templated with a policy, like even something as trivial sign().

There you go, stripping boost only requires 1300 lines of code to implement two math functions. Nice and succinct in typical boost fashion.

Don't know what's going on but the Python/windows build configuration always fails with: ``` python setup.py bdist_wheel did not run successfully. exit code: 1 [6 lines of output] usage: setup.py...

Otherwise are you happy with the code ?

Sorry i modified the API. I've opted for using strong types and function overloading for kaiser() instead of different function signatures. I think it's clearer and the user has to...

Ok I think I have everything I need now. So if unit tests pass, we're good to go. For those who are interested, next PR will be STFT and ISTFT....

@davisking what do you think ? Ok or horse manure ?