-
Notifications
You must be signed in to change notification settings - Fork 55
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
Implemented rfft!
, irfft!
and brfft!
#222
base: master
Are you sure you want to change the base?
Conversation
The new functions work with a new `PaddedRFFTArray` type. They also work with appropriately sized Compex Arrays and Real Subarrays.
…ed to solve ambiguity. Same for `brfft!(f::PaddedRFFTArray, i::Integer)`
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #222 +/- ##
==========================================
+ Coverage 62.67% 68.14% +5.46%
==========================================
Files 5 6 +1
Lines 434 565 +131
==========================================
+ Hits 272 385 +113
- Misses 162 180 +18 ☔ View full report in Codecov by Sentry. |
The transformation was not really in-place.
…exOrRealReinterpretArray`
…rrays. - `PaddedRFFTArray` now accepts any `AbstractArray` type, provided the strides are continuous. - Changed some variable names to be consistent with other functions (`d` is always the length of the first dimension of the logical real array)
Is there any progress on this PR? This would be very useful for us to have in TimeseriesSurrogates.jl, where performance of some of our methods would be improved if the in-place inverse transform |
This PR supersedes #54 .
Most of the code is the same.
It provides the same features but adds the capability of calling
irfft!(c::Array{Complex},d::Integer)
andrfft!(r::SubArray{<:Real}
which are implicitly converted toPaddedRFFTArray
. This makes it much simpler to convert code usingrfft
andirfft
to use the in-place versions of thoseIn order to implement those features, we must allow
PaddedRFFTArray
to be initialized with a complex array, in which case the real view of the array must be reinterpreted out the complex array.Although there is a way to make reinterpreted real-to-complex array performant (see Tim Holy's comment), it doesn't seem the same trick can be used to make reinterpreted complex-to-real arrays performant.
In this PR I'm using an internal
ComplexOrRealReinterpretArray
that relies on loading and storing directly from pointers to the raw data, whileGC.@preserve
ing appropriately the underlying data.To Do:
rfft!(a::PaddedRFFTArray,region=1:ndims(a))
andrfft!(a::DenseArray{<:Complex},d::Integer)
in a better way