Refactor of operator typing

[kylebeggs]

This PR removes a layer of unnecessary wrappers around our operators and reuses all possible arrays when building multiple weight matrices such as needed for Gradient.

[github-actions]

Benchmark Results

	main	0dd5c7f...	main / 0dd5c7f...
time_to_load	0.49 ± 0.0027 s	0.5 ± 0.0018 s	0.979

Benchmark Plots

A plot of the benchmark results have been uploaded as an artifact to the workflow run for this PR.
Go to "Actions"->"Benchmark a pull request"->[the most recent run]->"Artifacts" (at the bottom).

[Davide-Miotti]

Hi, I think all of your modifications are great!
I only have 2 remarks/ideas:

1. what do you think of pre-allocating 2 sets of I,J,V, since you already have the adjacency adjil in _build_weights you could count the number of internal and boundary nodes for each line and get the 2 matrices (one for internal and one for boundary right from the start), do you believe this is premature optimization?
2. what about creating a struct for local data, so that _build_stencil!, _build_collocation_matrix! and _build_rhs! can become methods of that struct and thus have less inputs?

[Davide-Miotti]

all of these seem clear improvements to me

[kylebeggs]

1. what do you think of pre-allocating 2 sets of I,J,V, since you already have the adjacency adjil in _build_weights you could count the number of internal and boundary nodes for each line and get the 2 matrices (one for internal and one for boundary right from the start), do you believe this is premature optimization?

I'm not sure I follow what you mean here.

2. what about creating a struct for local data, so that _build_stencil!, _build_collocation_matrix! and _build_rhs! can become methods of that struct and thus have less inputs?

I definitely agree those functions are a bit messy and have a lot of inputs, but I'm not sure what this would help with besides cleaning the code some. I'm concerned we would not be able to do it without losing performance. If we won't lose any performance, then I am good with doing it. I suggest to merge this one soon with some official benchmarks and then we can open another PR to do that and it will compare the performance.

Another thing is I'm struggling to figure out with this new refactor is the operator combinations. It would be nice if we could be able to do things like $\partial x + \partial y$ to get a single operator instead of adding the results. Things like this would be twice as fast. maybe we can remove this for now and come back to it later.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Files with missing lines	Coverage Δ
src/RadialBasisFunctions.jl	100.00% <ø> (ø)
src/basis/monomial.jl	100.00% <100.00%> (ø)
src/basis/polyharmonic_spline.jl	100.00% <100.00%> (ø)
src/operators/custom.jl	100.00% <100.00%> (ø)
src/operators/directional.jl	100.00% <100.00%> (ø)
src/operators/gradient.jl	100.00% <100.00%> (ø)
src/operators/laplacian.jl	100.00% <100.00%> (ø)
src/operators/monomial/monomial.jl	92.53% <ø> (-0.22%)	⬇️
src/operators/operator_algebra.jl	100.00% <100.00%> (+8.69%)	⬆️
src/operators/operators.jl	100.00% <100.00%> (ø)
... and 2 more

🚀 New features to boost your workflow:

• ❄ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[kylebeggs]

The benchmark isn't passing because it tries to run on the previous commit which it can't because there are breaking changes.