Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Numerical evaluation of Fourier transform of Daubechies scaling funct… #921

Merged
merged 9 commits into from
Jun 13, 2023

Conversation

NAThompson
Copy link
Collaborator

…ions.

@NAThompson NAThompson force-pushed the ft_daubechies branch 5 times, most recently from 40909f0 to c4b0791 Compare January 17, 2023 04:19
Copy link
Member

@mborland mborland left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

General pedantic things. I'll read the paper this week so I can be more constructive.

@NAThompson NAThompson force-pushed the ft_daubechies branch 2 times, most recently from 5c65458 to 4adbc27 Compare January 18, 2023 04:20
@NAThompson
Copy link
Collaborator Author

@jeremy-murphy : Your polynomial division algorithm is amazing; super fast and it looks like every recovered digit is correct.

@jeremy-murphy
Copy link
Contributor

@jeremy-murphy : Your polynomial division algorithm is amazing; super fast and it looks like every recovered digit is correct.

Are you serious? I actually wouldn't have expected it.

Credit for the algorithm goes to Knuth, I just implemented it.

@jeremy-murphy
Copy link
Contributor

Anyway, if I stop being grumpy for a moment: that's great news! :)

@NAThompson NAThompson force-pushed the ft_daubechies branch 2 times, most recently from 702b407 to bbea451 Compare January 19, 2023 04:00
@NAThompson NAThompson marked this pull request as draft January 19, 2023 04:12
@NAThompson
Copy link
Collaborator Author

@jeremy-murphy , @jzmaddock , @mborland , @ckormanyos : Obviously don't want to burden you guys with a problem you think is uninteresting, but I figured I'd at least try to plea for help. The accuracy here without argument promotion just seems unacceptable-for instance without arg promotion it appears that up to 8 mantissa bits are incorrect in float precision. Arg promotion leads to extreme additional computational expense.

Maybe this is a "no solutions, only tradeoffs" situation, but I'd figure I'd at least see if there's anything obvious we can do.

@jzmaddock
Copy link
Collaborator

I'll try and take a look.

@NAThompson
Copy link
Collaborator Author

Screenshot 2023-01-21 at 2 02 54 PM

This is an ULP plot of the 6-vanishing moment implementation; you can see it's all over the place. The red line over the top indicates that worse values have been clipped.

@mborland
Copy link
Member

Screenshot 2023-01-21 at 2 02 54 PM

This is an ULP plot of the 6-vanishing moment implementation; you can see it's all over the place. The red line over the top indicates that worse values have been clipped.

Is this with or without promotion in place?

@NAThompson
Copy link
Collaborator Author

Is this with or without promotion in place?

No arg promotion-actually with arg promotion this would be tautologically 0 everywhere.

@NAThompson
Copy link
Collaborator Author

As you might expect, we do better with fewer moments, but still not up to snuff:

Screenshot 2023-01-21 at 2 22 52 PM

@NAThompson
Copy link
Collaborator Author

Condition number of function evaluation revealed to be fairly bad by putting the ULP envelope around it:

Screenshot 2023-01-21 at 2 26 21 PM

@jeremy-murphy
Copy link
Contributor

@jeremy-murphy , @jzmaddock , @mborland , @ckormanyos : Obviously don't want to burden you guys with a problem you think is uninteresting, but I figured I'd at least try to plea for help. The accuracy here without argument promotion just seems unacceptable-for instance without arg promotion it appears that up to 8 mantissa bits are incorrect in float precision. Arg promotion leads to extreme additional computational expense.

Maybe this is a "no solutions, only tradeoffs" situation, but I'd figure I'd at least see if there's anything obvious we can do.

On the contrary, it sounds very interesting, and I wish I had time to help, but I don't.

Maybe only certain operations need the extra accuracy afforded by arg promotion?

@jeremy-murphy
Copy link
Contributor

I haven't found the literature that defines the ratio for choosing an algorithm for polynomial evaluation, but I did find this reference, which may help you:

S. Graillat, P. Langlois, and N. Louvet. Algorithms for accurate, vali-
dated and fast computations with polynomials. Japan Journal of Indus-
trial and Applied Mathematics, 26(2):215–231, 2009.

The textbook I got that reference from (Handbook of Floating-Point Arithmetic, 2nd ed.) suggests to take the "Graillat–Langlois–Louvet error-free transformation" and make it a compensated summation using the same principle as Kahan's summation. I can give you more details if you're interested.

@NAThompson
Copy link
Collaborator Author

I can give you more details if you're interested.

Yes, I'm interested. This particular algorithm has some trouble with compensated summation, because it's actually an infinite product where each term is a small polynomial. I think I might actually need some sort of "compensated product", if that even makes sense in floating point.

@NAThompson
Copy link
Collaborator Author

NAThompson commented Feb 4, 2023

Well the color scheme is absolutely grotesque, but it appears to be correct:

Screenshot 2023-02-04 at 1 48 23 PM

@NAThompson NAThompson force-pushed the ft_daubechies branch 8 times, most recently from f25ec93 to 6db459e Compare February 6, 2023 05:19
@NAThompson NAThompson force-pushed the ft_daubechies branch 3 times, most recently from 101e952 to 841795b Compare June 11, 2023 20:54
@NAThompson NAThompson marked this pull request as ready for review June 11, 2023 20:55
@NAThompson
Copy link
Collaborator Author

@jzmaddock , @mborland : I've finally gotten this working; mind giving it a look?

example/fourier_transform_daubechies_ulp_plot.cpp Outdated Show resolved Hide resolved
// we'd immediately just have to divide through by 1/sqrt(2).
// These numbers agree with Table 6.2, but are generated via example/calculate_fourier_transform_daubechies_constants.cpp
template <typename Real, unsigned N> constexpr const std::array<Real, N> ft_daubechies_scaling_polynomial_coefficients() {
static_assert(N >= 1 && N <= 10, "Scaling function only implemented for 1-10 vanishing moments.");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a way to compute the constants outside of this range on an as-needed basis like calculate_constants?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not really, especially since I want it in a constexpr std::array . . .

The calculation is rather involved.. .

test/fourier_transform_daubechies_scaling_test.cpp Outdated Show resolved Hide resolved
test/fourier_transform_daubechies_scaling_test.cpp Outdated Show resolved Hide resolved
test/math_unit_test.hpp Outdated Show resolved Hide resolved
@NAThompson NAThompson merged commit 7887d43 into develop Jun 13, 2023
@NAThompson NAThompson deleted the ft_daubechies branch June 13, 2023 15:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants