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

Decide how we should deal with math/special_functions/chebyshev_transform.hpp #20

Open
cosurgi opened this issue Aug 6, 2021 · 5 comments

Comments

@cosurgi
Copy link
Collaborator

cosurgi commented Aug 6, 2021

The file chebyshev_transform.hpp uses FFT. We should know how to deal with this.

@cosurgi
Copy link
Collaborator Author

cosurgi commented Aug 7, 2021

Ignoring this is also one of possible solutions. Usually these kinds of architectural problems led to a better design overall, and required drastic redesign along the way.

@ckormanyos
Copy link
Member

file chebyshev_transform.hpp uses FFT. We should know how to deal with this.

I had noticed that as well.

Ignoring this is also one of possible solutions.

My strategy had been (and continues to be) along the lines of ignoring, but not entirely and forever. Rather, igonre until we have a specified and established interface (including the exact function needed in that place) and then simply replace with the generic interface with default BSL parameterization and optional FFTW for optimization. But I never contacted the other original author of that work regarding this issue yet.

@cosurgi
Copy link
Collaborator Author

cosurgi commented Aug 9, 2021

and then simply replace with the generic interface with default BSL parameterization and optional FFTW for optimization.

Yes. I guess this is our target goal here. I mentioned in one of other comments: if we want Boost.Math to not depend on Boost.Multiprecision and vice versa, then probably our work here should end up in a new library Boost.FFT.

EDIT: I believe the conclusion is to stay in Boost.Math, at least for now. The careful required considerations for this are in the linked post.

@Lagrang3
Copy link
Collaborator

Lagrang3 commented Aug 14, 2021

I did take a look at that file. There is no straightforward way to do the FFTW_REDFT10 transform with our current interface. That one is a particular type of transform from the family of the discrete cosine transforms (DCT). We could probably express those DCTs as convolutions and then compute the convolutions using our interface, but that would not be as performant as a dedicated code to DCTs alone.

@ckormanyos
Copy link
Member

no straightforward way to do the FFTW_REDFT10 transform with our current interface.

This means... post-GSoC21 in my world, unless it's simpler than it seems from your description.

Eduardo, you have accomplishe so much in this short time. I'm not sure if we should open a topic having such wide scope and depth on the final weekend. Kind of getting toward wrap-up/report time soon.

@Lagrang3 and @cosurgi

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

No branches or pull requests

3 participants