-
Notifications
You must be signed in to change notification settings - Fork 27
WIP: Support 0.6 #13
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
WIP: Support 0.6 #13
Conversation
• Drops 0.4 support
We can't merge this until we have a solution to JuliaLang/Compat.jl#312 |
As 0.5 compatibility is broken |
I'm confused by your bigfloat FFT test. Julia has never included a bigfloat FFT (if you pass it bigfloats, it converts to Float64). I had an rough PR for this at one point, but it was never merged. |
Mikael implemented an FFT for |
The implementation would also work for other types... @stevengj do you think it would be worth creating an FFT.jl package and putting it there (until a more robust implementation is developed)? |
See also JuliaLang/julia#6193 for my bigfloat implementation, which also used Bluestein combined with radix-2 IIRC ... yes, but at some point the |
I don't have an issue with this. The BigFloat FFT hasn't been optimized, but it has been useful from time to time. |
This is actually a bug in Julia 0.6: JuliaLang/julia#20381 I can't work around it using colon: JuliaLang/julia#20382 |
The bug was fixed in 0.6 master |
This starts supporting 0.6. I've dropped 0.4 compatibility so that the
f.(x)
syntax can be used. Are we OK with this change? (I think@compat
can restore 0.4 compatibility but I'm not sure it's worth it.)the BigFloat FFT test fails for some reason: