kfr::complex / std::complex troubles

[mipac]

Hi, I have trouble with float complex type. I try to use std::complex to make easier the integration with other code and I have compiler errors. for example with the resampler:

.../include/kfr/dsp/sample_rate_conversion.hpp:115:25: error: invalid operands to binary expression ('kfr::sse2::samplerate_converter<std::complex >::ftype' (aka 'std::complex') and 'const long') cutoff = cutoff / std::max(decimation_factor, interpolation_factor);

.../include/kfr/dsp/sample_rate_conversion.hpp:404:12: note: in instantiation of member function 'kfr::sse2::samplerate_converter<std::complex<float> >::samplerate_converter' requested here
    return samplerate_converter<T>(quality, itype(interpolation_factor), itype(decimation_factor), scale,
           ^

there is other errors with other kfr object, the resampler is just an example.

Is kfr::c32 totally compatible with std::complex<float>
Or, what is the purpose of that type? Is it necessary to have 2 complex types?

to bypass the problem I implement my dsp classes with kfr::complex<float> and "cast" from my calling code with:
`auto ucpx = make_univector<kfr::c32>( reinterpret_cast<kfr::c32*>(m_cpx_buffer.data()), m_cpx_buffer.size());`

Is it correct?
Is there a better way?

with my best regards

[dancazarin]

Hi,

reinterpret_cast is absolutely correct here as the complex types have same layout in memory. The custom type for complex values is intended for better conversion performance in FFT code. The issue with combining std and kfr types will be resolved in the next release (that is in progress).

Best regards

[mipac]

great! thanks a lot

[mipac]

I'm not sure to understand well, does it mean that fft with std is less optimal? what do you mean by conversion ?

[dancazarin]

The performance impact is negligible for most cases and only affects passing and receiving data to/from KFR algorithms. Internally, DFT and other DSP algorithms in KFR don't do conversion at all and use vectors of regular floating point types with highly optimized functions doing all required complex math under the hood.

The fix for using std::complex has been pushed to dev. Now you can use KFR_STD_COMPLEX cmake parameter to control using std::complex for data passing/receiving data. Set it to ON and rebuild KFR to make kfr::complex<> an alias for std::complex<>.

[mipac]

thank you very much