firionus / nonuniformresampling1d.jl Goto Github PK

Come up with a good way to state the requirements and how to test them.

Currently, an error is thrown if out-of-bounds points would be required. I think this is a good default behavior, but for advanced usage some boundary conditions would be useful like:

• Mirror-Periodic
• Periodic
• OnGrid/OnCell (see Interpolations.jl for the meaning)

During early development, I noticed that the use case of resampling from arbitrary grids to something else is a bit too special for me. Therefore, I'll focus on resampling from uniform to nonuniform grids with the main goal of smoothing FFT data, even though upsampling would also be supported.

Alternative Name: NonuniformResampling

Pros:

• Better describes that this package completely provides resampling from uniform to nonuniform sample locations

Cons:

• Doesn't really describe that it only works in 1D, but none of the names I know would do that
• Doesn't really describe that sampling from nonuniform grids is not supported
• Does not emphasize that smoothing is the target use case

EDIT: ToDo

• Rename Basis Functions
  • rename type to Kernel/Window/... ?
  • rename individual functions to not clash with DSP.jl and to follow Julia conventions
    • rectwin: not very readable with the mashed abbreviations
    • WindowFuncitons.rect: long, wordy, the important part (rect) at the end
    • rect_window: my favorite so far
  • associated functions?
  • associated comments, file names and docs
• Rename main API
  • regrid -> resample/nuresample/resample1d/nuresample1d/... ?
• Rename library to NonuniformResampling/NonuniformResampling1D
  • New repo or rename? What happens when you change the name in Project.toml?
  • following https://github.com/JuliaRegistries/General#how-do-i-rename-an-existing-registered-package

EDIT: I think this would be better put into a separate package that depends on this one, called something like "NonuniformSmoothing1D".

Move private implementations for logrange and polyrange into the repo.

Improve the API to be as close to Base's range as possible. Use something like step=1/24, base=2 for 24 points per octave in logrange.

Check if it makes sense to return an iterator instead of an array (see here: https://stackoverflow.com/questions/59985035/does-there-exist-any-alternative-of-logspace-in-julia-v1-3-1/59987565#59987565)

The end goal is to have a high level API to perform log or poly non-linear smoothing.

For example, emulate the behavior of normalize in LinearAlgebra:
https://github.com/JuliaLang/julia/blob/bf534986350a991e4a1b29126de0342ffd76205e/stdlib/LinearAlgebra/src/generic.jl#L1744-L1787

• Which types should the public API accept?
• What about OffsetArrays?

• Give status hint in README
• Fix #8
• Make sure we're ready for a first release
• Is there an advantage to doing a GitHub release? Don't think so.
• Keep main as release branch, document that dev branches need to be used for further development
• Tag first release

Some suggested content:

• API Docs
• Document return values of functions. Follow this template: https://discourse.julialang.org/t/coordinating-community-efforts-to-enrich-function-docs/80338/45
• There should be a diagram and concise explanation of the resampling approach in the README.
  • Create Diagram Code
  • Set Up Documenter and README Documentation
  • Is Doctest run?
  • Document an Example in the docstring where all args are used
  • Document how to construct and call your own window functions
• Diagrams and Explanations of the different windows and their parameters

Examples, e.g. frequency response measurements -> do that in smoothing library

There should be a diagram and concise explanation of the resampling approach in the README.

E.g. use the hopefully already existing examples. This should be low priority.

Once done, the following list of performance concerns could be tackled:

• Float64(xin.step) is calculated again and again in different places -> bad?
• use buffer for upsampled values that is allocated at a call to regrid instead of allocating every time. Problem: With current upsampling scheme, the maximum length required for this buffer is not well defined.

see https://docs.julialang.org/en/v1/base/base/#Base.@assert

We must not rely on AssertionErrors for e.g. input validation.

Perform a Style Check, etc.

• VS Code Linter
• Aqua.jl