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 (?). - 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. Aaron Meurer -- 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.
