Add inverse to QFT implementation #705
Conversation
quest/include/operations.h
Outdated
| * | ||
| * @formulae | ||
| * | ||
| * Let @f$ N @f$ = @p numTargets, the @f$ N @f$ qubit Quantum Fourier Transform maps each |
quest/include/operations.h
Outdated
| * @formulae | ||
| * | ||
| * Let @f$ N @f$ = @p numTargets, the @f$ N @f$ qubit Quantum Fourier Transform maps each | ||
| * computational basis state belonging to the targeted qubits, @f$ \ket{j} @f$, according to |
| * @param[in] inverse whether to apply the inverse QFT or forward QFT | ||
| * @throws @validationerror | ||
| * - if @p qureg is uninitialised. | ||
| * - if @p targets are invalid qubit indices. |
There was a problem hiding this comment.
add:
if @p targets are not unique.
| * - applyFullQuantumFourierTransform() | ||
| * @author Vasco Ferreira | ||
| */ | ||
| void applyQuantumFourierTransform(Qureg qureg, int* targets, int numTargets, bool inverse); |
There was a problem hiding this comment.
Technically, type bool is only gauranteed to be defined in C when including the <stdbool.h> header. That header is in the standard since C99 however. @otbrown thoughts on this? This is the first bool in the QuEST API (ignoring measurement outcomes passed as int). Should we make inverse an int and validate it to be ==0 or ==1 (like measurement outcomes), or just include the header?
There was a problem hiding this comment.
Happy to update this, just a note that PR #702 also included a bool (and the <stdbool.h> header for C), so if we do end up going with the int and validation route, it might make sense to update that too.
There was a problem hiding this comment.
Good catch @TysonRayJones!
My thoughts are that:
- We are already using the C11 standard, so introducing
stdbool.hdoesn't introduce any build issues or push our requirements. - Practically, bool vs int makes very little difference as they are somewhat interchangeable in C, however bool has a semantic benefit, as it better expresses intent.
So in my opinion we should include stdbool.h and use bool here.
3 participants
Howdy, I hope your holidays and the start of the new year have been great!
While the refactor of the QFT implementation in #604 remains in the backlog, I think it would still prove useful to have an inverse QFT for completeness. Since I needed this for another project and it is a fairly minor change I figured it might be worth tidying it and submitting a PR.
Main changes:
inverseparameter, which is a breaking change, but I think it makes sense to keep the QFT and inverse together. Happy to split it if you disagree.Cheers!