Skip to content
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

top-level documentation for inverse real needs clarification #49

Open
mdarnold1 opened this issue May 29, 2020 · 3 comments
Open

top-level documentation for inverse real needs clarification #49

mdarnold1 opened this issue May 29, 2020 · 3 comments
Labels

Comments

@mdarnold1
Copy link

The top-level documentation does not make it clear that the inverse real transforms are real to complex (not complex to real as some users will expect).

Also, this functionality is very much less useful than complex to real, which is something to consider for future work. I know that this is available through the numpy interface, but numpy lacks the overwrite flag.

@oleksandr-pavlyk
Copy link
Collaborator

oleksandr-pavlyk commented Jun 5, 2020

Were you looking for mkl_fft.rfft_numpy and mkl_fft.irfft_numpy?

In [8]: mkl_fft.rfft_numpy(np.arange(-4, 4, dtype='d'))
Out[8]:
array([-4.+0.j        , -4.+9.65685425j, -4.+4.j        , -4.+1.65685425j,
       -4.+0.j        ])

In [9]: mkl_fft.irfft_numpy(_)
Out[9]: array([-4., -3., -2., -1.,  0.,  1.,  2.,  3.])

I must point out that they also do not support overwrite_x keyword, because the transform may require one element more that the input array:

In [10]: mkl_fft.rfftn_numpy(np.arange(-4,4, dtype='d')).nbytes                                                                                         
Out[10]: 80

In [11]: np.arange(-4,4, dtype='d').nbytes                                                                                                              
Out[11]: 64  

@mdarnold1
Copy link
Author

Yes I'm aware of the numpy versions. On closer inspection of mkl_fft.rfft & mkl_fft.irfft, I see that they are inverses (my mistake), but I still think the top level documentation should explain the data format for both of these.

@mdarnold1
Copy link
Author

With respect to overwrite, yes I understand that the input has to be padded which does present some difficult choices for the interface, but it would be nice to have this capability.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants