Closed willGraham01 closed 1 year ago
Patch coverage: 70
% and no project coverage change.
Comparison is base (
fdbfc93
) 26% compared to head (4154d3d
) 26%.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.
Totally fine with this... but I'm a bit sad that I can't have a
Matrix<std::complex>
.What was the error?
Matrix<std::complex>
doesn't complain - it's Matrix<fftw_complex>
which does. This is because fftw_complex
is a typedef of double[2]
, and then some obscure error that I think boils down to the fact that an fftw_complex
is a double*
so can't be used in the template.
Description
The
EHVec
class is currently a publicMatrix<fftw_complex>
. It is desirable to convertMatrix<>
to used strided vector storage and remove any MATLAB dependencies.The former doesn't work for
EHVec
since thefftw_complex
type is a double[2], which throws an error when used in templatedstd::vector<T>
functions. Additionally,EHVec
is used in such a way thatfftw
needs a continuous buffer to perform the forward/backward transform, which a strided vector does not guarantee.As such, it is necessary to provide
EHVec
with it's own (MATLAB-free) class. This enablesMatrix
and its other derivatives to be freed of MATLAB influence.EHVec
task.main
.Testing
EHVec
continue to pass after the refactor.EHVecTest
class since it is no longer a member of thearrays.h
file, and it only had a single unit test in the first place (so a class was overkill).