Refactoring SWT for libtopotoolbox
Nobody has claimed this yet.
- Dominant language
- C
- Stars
- 0
- Forks
- 2
- PR merge metrics
- No merged PRs in 30d
Description
For inclusion in libtopotoolbox, we need to refactor the existing SWT functions so that it does no I/O and takes all of its input and output arrays as parameters.
We will probably end up with an interface like
void wavelet(float *WavCoeff, float *WavFilt,
const float *distance, const float *depth,
ptrdiff_t numlines, float maxscale);
The float * arguments are the output arguments. These will be pointers to arrays that are passed into wavelet by the caller to be filled up with the results. The const float * arguments are the inputs. Then you have the sizes of all of these arrays (ptrdiff_t numlines). We typically use ptrdiff_t, which is a type defined in stddef.h for array sizes and element counts. And then you have other parameters that the function needs, like the maximum scale.
Exactly what this interface looks like can be worked out as we refactor. We may prefer a single function like wavelet that does the complete analysis or a series of functions like wavCompute, wavInterp, etc. that users would call in sequence to conduct the analysis.
I would start by working from the bottom up: the actual work is done in functions like wavCompute and wavInterpii. Go through those and remove things like printf that perform I/O. At a glance, most of the print statements in wavCompute are for debugging purposes and go to stdout, which we don't explicitly check in the tests. If you want to just remove those, it should therefore work without affecting the tests. Alternatively you could call wavCompute and then add a new function (wavComputeDebug) that scans through the computed coefficients and outputs the necessary information.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the existing wavCompute and wavInterpii functions, tracing how they perform computation, I/O, and exchange arrays. Review the existing tests while deciding whether one wavelet function or a sequence of functions fits the refactor. Done means the SWT computation accepts its inputs and outputs through parameters, performs no I/O, and continues passing the tests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c
- Domain
- data
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100