You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello,
I would like to suggest two small improvements:
The EstimationProblem, when not explicitely given a Grover oracle, automatically produces one. Unfortunately, this standard oracle uses the multi-controlled NOT with 'noancillas' mode (lines 168 and 172), which is highly inefficient in terms of circuit depth (it scales as 2**n, where n is the number of qubits, while other implementations scale as n, at the expense of a higher width - refer to mcx). This behavior is very bad as it may strongly affect the performances in applications. I suggest we expose the mcx_mode in the EstimationProblem function, as currently done in GroverOperator. We shall also discuss which value should be the default for mcx_mode: 'noancillas' for backward compatibility?
The EstimationProblem has a parameter is_good_state, but the standard QAE is not able to handle it, for obvious reasons. This fact is very confusing. I think we should have a variable to keep trace whether is_good_state is not the default one, and AmplitudeEstimation should throw an exception if given an EstimationProblem with a user-defined is_good_state
I can contribute with the code, if you agree.
The text was updated successfully, but these errors were encountered:
What should we add?
Hello,
I would like to suggest two small improvements:
'noancillas'
mode (lines 168 and 172), which is highly inefficient in terms of circuit depth (it scales as2**n
, wheren
is the number of qubits, while other implementations scale asn
, at the expense of a higher width - refer to mcx). This behavior is very bad as it may strongly affect the performances in applications. I suggest we expose themcx_mode
in the EstimationProblem function, as currently done in GroverOperator. We shall also discuss which value should be the default formcx_mode
:'noancillas'
for backward compatibility?is_good_state
, but the standard QAE is not able to handle it, for obvious reasons. This fact is very confusing. I think we should have a variable to keep trace whetheris_good_state
is not the default one, and AmplitudeEstimation should throw an exception if given an EstimationProblem with a user-definedis_good_state
I can contribute with the code, if you agree.
The text was updated successfully, but these errors were encountered: