Created
February 1, 2017 22:49
-
-
Save geggo/6bbc597439ffbec596353cf699fb025c to your computer and use it in GitHub Desktop.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This summarizes the issues nicely. Thanks.
I've been wavering between thinking real in-place should look similar to out-of-place (Option 2, what you currently have in commit geggo/gpyfft@2c07fa8) and real in-place should look similar to complex in-place (Option 1, what I have in SyamGadde/gpyfft@f39da92). But your option seems simpler. I've modified my test script (below) and it works well with your current commit. I think I can incorporate some of my bounds/stride checking to make it more idiot-proof (I include myself among them).
I do think having convenience functions to create the padded arrays would also be very helpful to the user, and a separate
enqueue_real
function would eliminate some of the ambiguity in usage -- the mainenqueue
function could still have the full functionality, but the wrapper could remove some of the guesswork (sending real=True appropriately, maybe even returning the correct output view).Test script: