I just noticed that the property .targets is already what you are saying target_qubits should be. Should I just use that instead?
Aaron Meurer On Fri, Jul 20, 2012 at 9:51 PM, Aaron Meurer <[email protected]> wrote: > One question, as long as I'm digging into the quantum stuff. What's > the purpose of the .label property? Isn't it the same as .args? > > Aaron Meurer > > On Thu, Jul 19, 2012 at 11:11 AM, Brian Granger <[email protected]> wrote: >> On Wed, Jul 18, 2012 at 6:05 PM, Aaron Meurer <[email protected]> wrote: >>> On Wed, Jul 18, 2012 at 6:40 PM, Brian Granger <[email protected]> wrote: >>>> On Wed, Jul 18, 2012 at 12:13 PM, Aaron Meurer <[email protected]> wrote: >>>>> In my branch where I'm fixing expand, I've moved the base _eval_expand >>>>> functions to Expr. The result is that for expand to work on an >>>>> object, it must be rebuildable via obj.func(*obj.args). >>>>> >>>>> There are two classes in the quantum module that came up where this >>>>> doesn't work. One is OracleGate, which is built like OracleGate(2, >>>>> lambda qubits: qubits == IntQubit(2)), which produces the .args ((0, >>>>> 1), lambda qubits: qubits == IntQubit(2)) (in general, the first >>>>> argument n is converted to range(n)). The second is WGate, which >>>>> works like WGate(3), which produces the .args (2, 1, 0) (in general, >>>>> an argument n produces reversed(range(n))). >>>>> >>>>> I was able to change OracleGate to accept its args without ambiguity. >>>>> If the first argument is an integer, it does what it does now. If >>>>> it's a tuple, succeed if it's of the form of range(N) for some N. >>>>> >>>>> WGate cannot be fixed like this, though, because there is ambiguity >>>>> for WGate(0), which can be construed as either WGate(1) or WGate() >>>>> (range(1) or range(0)). >>>>> >>>>> Since I know very little about quantum computing and Grover's >>>>> algorithm, I'd like to know what the best way to fix this is. The >>>>> options are see are: >>>>> >>>>> - Make WGate(0) be construed as range(1). Currently WGate(0) doesn't >>>>> work, which leads me to believe that you can't have a gate with 0 >>>>> quibits. This would not require breaking the current API, but might >>>>> be confusing (?). >>>> >>>> You need to have at least 1 qubit for it to make sense. WGate(0) >>>> should really raise a ValueError. >>> >>> Right. WGate(0) would be the rebuild of WGate(1) (if that makes sense). >>> >>>> >>>>> - Break the API. Since any kind of break would be equally disruptive, >>>>> I would suggest moving to just storing n in .args, and constructing >>>>> reversed(range(n)) on the fly when it's needed. Alternately, we could >>>>> store (reversed(range(n)),), which would make it similar to >>>>> OracleGate. >>>> >>>> Yes, let's to that. Just make a property that returns >>>> reversed(range(n)) and use that when needed. >>> >>> OK. What should it be called? .quibits I guess. Should OracleGate >>> (and maybe others?) also be changed? >> I would call it target_qubits and OracleGate should have the same thing. >> >> Cheers, >> >> Brian >> >>> Aaron Meurer >>> >>>> >>>> Does this answer your questions? >>>> >>>> Cheers, >>>> >>>> Brian >>>> >>>> >>>>> Aaron Meurer >>>> >>>> >>>> >>>> -- >>>> Brian E. Granger >>>> Cal Poly State University, San Luis Obispo >>>> [email protected] and [email protected] >> >> >> >> -- >> Brian E. Granger >> Cal Poly State University, San Luis Obispo >> [email protected] and [email protected] -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
