Open cdeterman opened 7 years ago
Experimental refers to "the implementation passes tests, but the API is not stable, nor do we claim any kind of high performance nor robustness for corner cases."
(a classic implication of a contributed piece of functionality where the contributor is long gone)
A follow-up to this initial question. The output of the FFT results in the following output:
input_vec: [16](0,0,1,0,2,0,3,0,4,0,5,0,6,0,7,0)
output_vec: [16](28,0,-4,9.65685,-4,4,-4,1.65685,-4,0,-4,-1.65685,-4,-4,-4,-9.65685)
If I do the same thing in R I get the output:
fft(c(0,0,1,0,2,0,3,0,4,0,5,0,6,0,7,0))
[1] 28+0.000000i -4+9.656854i -4+4.000000i -4+1.656854i -4+0.000000i -4-1.656854i -4-4.000000i -4-9.656854i 28+0.000000i -4+9.656854i
[11] -4+4.000000i -4+1.656854i -4+0.000000i -4-1.656854i -4-4.000000i -4-9.656854i
Clearly these don't appear to be the same results. Firstly, the R version returns complex
numbers. As far as I understand, the OpenCL doesn't support complex
data types here correct? If that is the case, how are the numbers returned by ViennaCL actually produced? It is very important I understand the results here before I can produce any downstream use of this functionality.
Thanks
Apologies for the late response... :-/ Because ViennaCL doesn't have 'native' complex numbers, the FFT module uses an interleaved storage format. That is, even entries are the real parts, while odd entries are the imaginary part. In you example above, output_vec[0] and output_vec[1] describe the value 28 + 0*i.
Ah, I see now, clever. That said though, I thought OpenCL does have complex
numbers. Here I find mention of complex
types in the 1.2 version of OpenCL here.
complex
is a reserved data type. This means that it may be introduced in a future standard as a native data type. Eventually. Or never...
This said, it is possible to just come up with a custom complex data type within OpenCL kernels. The downside is that arithmetic operators are not automatically overloaded. Not a blocker, but not very joyful programming either...
One more thought before I close this issue. Is this different if using the CUDA backend? I know CUDA supports the complex
data type.
It also appears unclear the use for the real_to_complex
and complex_to_real
functions.
The three backends behave in the same way. No complex
is used for CUDA. After all, the user API needs to be consistent across all three backends.
real_to_complex
interleaves the input vector with zeros (for the imaginary part). complex_to_real
extracts the real part (even entries of the input vector) and writes them to the output vector.
@karlrupp it has occurred to me, is there a way to convert a real matrix to a complex matrix in viennacl? I only see the real_to_complex
method defined for vectors.
@karlrupp just curious about the implementation of real_to_complex
. This is important as I am trying setup an interface to use these 'complex' data types. How I handle a conversion from a 'real' to 'complex' type is therefore of great interest to me.
So what is your intended use? Do you want to compute a 2D-FFT for a matrix?
@karlrupp yes, I am looking to interface with clFFT as well which supports 2D-FFT as well. As it would expect a complex matrix (denoted at interleaved) I would like to be able to convert a 'real' matrix in to that 'complex' format which appears to be the case for vectors with real_to_complex
.
What about plugging the memory handle from a matrix into a vector and then call 'real_to_complex' for that wrapper vector?
@karlrupp I think that should work. Would that update the dimensions of the matrix as well or would another matrix need to be initialized from that memory handle?
In the documentation it is noted that FFT is experimental. How experimental are we talking about here? If I chose to develop a function that utilizes the FFT here am I able to consider it functional and stable enough for end users? I don't mind updated the API if necessary I just want to be sure the functions operate correctly.