-
Notifications
You must be signed in to change notification settings - Fork 1
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
Comments
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. |
I had noticed that as well.
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. |
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. |
I did take a look at that file. There is no straightforward way to do the |
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. |
The file chebyshev_transform.hpp uses FFT. We should know how to deal with this.
The text was updated successfully, but these errors were encountered: