Description
The FLEBasis2D
code (#693), in its original port from the fle_2d
package, used a different grid convention for odd resolutions than ASPIRE's FBBasis2D
code. This became apparent when calling evaluate()
on one-hot stacks of coefficients resulted in slightly different basis functions between the two codes for odd resolutions. See #738.
@j-c-c originally pointed out that we could substitute ASPIRE's grid_2d
to generate the correct grid to match FB, which is here:
ASPIRE-Python/src/aspire/basis/fle_2d.py
Lines 206 to 212 in fb5e445
This grid fixes the slow FLE matrix multiplication method of evaluating coefficients, as the grid generated here is used in the construction of the dense matrix:
ASPIRE-Python/src/aspire/basis/fle_2d.py
Lines 638 to 657 in fb5e445
Unfortunately, this change does not fix the fast evaluate
and evaluate_t
results. These use a different grid, generated in FLEBasis2D._compute_nufft_gridpoints()
:
ASPIRE-Python/src/aspire/basis/fle_2d.py
Lines 261 to 285 in fb5e445
These are used in step1_t
of evaluate_t
and step1
of evaluate
:
step1_t()
ASPIRE-Python/src/aspire/basis/fle_2d.py
Lines 516 to 523 in fb5e445
step1()
ASPIRE-Python/src/aspire/basis/fle_2d.py
Lines 624 to 630 in fb5e445
Now that the FLE code orders the functions the same way by default, using the notebook in #738 can provide a way to visually compare the output of FBBasis2D
and the fast FLEBasis2D
methods. The knobs and levers that seem to adjust the exact distribution of energy over the grid seem to be the variables in the FLEBasis2D._compute_nufft_gridpoints()
method. Picking different numbers of radial and angular points, or adjusting the normalization of the gridpoints, has the effect of dilating or contracting the evaluated functions, or shifting their centers.
I think there is some combination of adjustments to the nufft grid that will achieve the same result as the grid fix for the slow matrix multiplication method.