Open hofirstb19 opened 2 years ago
Qubits need to be released to their 0 state in the same scope they have been allocated. You can try using the MeasureInteger
operation on summandLE
or reset all qubits explicitly with ResetAll
on summand explicitly.
Thanks for your reply, I think I see what you mean. However, when I measure the qubits using MultiM, there is no error even though there are qubits in non-zero state and not released. Is it a normal behavior?
And ... In the following test case, when using the IncrementByModularInteger
operation with increment in [132,765], modulus in [1,4] and the length of target less than 7, there exists a weird memory deallocation issue, even if having reset all qubits to 0 states. But the above range may have some deviation, the following example reports the error on my machine. Maybe it has something to do with the current memory allowance?
Testcase
namespace NISLNameSpace {
open Microsoft.Quantum.Intrinsic;
open Microsoft.Quantum.Measurement;
open Microsoft.Quantum.Arithmetic;
@EntryPoint()
operation main() : Unit {
mutable increment = 670;
mutable modulus = 3;
use NISLQubitArray38 = Qubit[7];
mutable target = LittleEndian(NISLQubitArray38);
IncrementByModularInteger(increment, modulus, target);
ResetAll(target!);
ResetAll(NISLQubitArray38);
}
}
Description:
In the following test case, there is a strange memory release problem when the non-all-zero qubits are not measured, and the error line information is ambiguous because there is nothing to do in line 13. At the same time, if the X operation replaces IncrementByModularInteger, the same phenomenon will occur. And MultiM operation does not reset the measured qubits to the |0⟩ state. So can you give me some suggestions about why this behavior occurred?
Testcase
Environment
operating system : Windows 11 dotnet version : 6.0.400 QDK : 0.25.228311