Closed jlapeyre closed 3 days ago
Files with Coverage Reduction | New Missed Lines | % | ||
---|---|---|---|---|
crates/accelerate/src/sparse_pauli_op.rs | 1 | 93.27% | ||
crates/qasm2/src/lex.rs | 5 | 92.37% | ||
crates/qasm2/src/parse.rs | 18 | 96.69% | ||
<!-- | Total: | 24 | --> |
Totals | |
---|---|
Change from base Build 9650973845: | -0.03% |
Covered Lines: | 63724 |
Relevant Lines: | 71022 |
One or more of the following people are relevant to this code:
@Qiskit/terra-core
@kevinhartman
@levbishop
@mtreinish
Files with Coverage Reduction | New Missed Lines | % | ||
---|---|---|---|---|
crates/accelerate/src/sparse_pauli_op.rs | 1 | 93.27% | ||
crates/qasm2/src/lex.rs | 5 | 92.11% | ||
<!-- | Total: | 6 | --> |
Totals | |
---|---|
Change from base Build 9661630219: | 0.006% |
Covered Lines: | 63725 |
Relevant Lines: | 71022 |
In an out of band discussion we agreed to reduce use of the constants PI2
and PI4
. In particular, the commit above that makes them pub const
has been overwritten to remove these in b6b315e .
The commit message for b6b315e is written as if the pub const
definitions never existed. So the message can be preserved as is in a squash commit. But the message for the commit introducing pub const PI2
etc. should be removed when squashing.
Changes Missing Coverage | Covered Lines | Changed/Added Lines | % | ||
---|---|---|---|---|---|
crates/circuit/src/operations.rs | 15 | 18 | 83.33% | ||
<!-- | Total: | 112 | 115 | 97.39% | --> |
Files with Coverage Reduction | New Missed Lines | % | ||
---|---|---|---|---|
crates/accelerate/src/sparse_pauli_op.rs | 1 | 93.27% | ||
crates/qasm2/src/lex.rs | 4 | 92.88% | ||
<!-- | Total: | 5 | --> |
Totals | |
---|---|
Change from base Build 9698604147: | 0.002% |
Covered Lines: | 63812 |
Relevant Lines: | 71092 |
Changes Missing Coverage | Covered Lines | Changed/Added Lines | % | ||
---|---|---|---|---|---|
crates/circuit/src/operations.rs | 15 | 18 | 83.33% | ||
<!-- | Total: | 112 | 115 | 97.39% | --> |
Files with Coverage Reduction | New Missed Lines | % | ||
---|---|---|---|---|
crates/accelerate/src/sparse_pauli_op.rs | 1 | 93.27% | ||
crates/qasm2/src/lex.rs | 3 | 92.88% | ||
crates/qasm2/src/parse.rs | 12 | 96.69% | ||
<!-- | Total: | 16 | --> |
Totals | |
---|---|
Change from base Build 9698604147: | -0.02% |
Covered Lines: | 63800 |
Relevant Lines: | 71092 |
Add constant abbreviations for some values and types.
This PR introduces some abbreviations for repetitive Rust code. Motivations are reducing clutter, improving readability, and perhaps modest support for rapid development.
Construction of complex numbers
Complex numbers are common in scientific computing and ubiquitous in quantum computation. They are supported in Rust via libraries, one in particular, with few ergonomic features beyond those provided for any
struct
. We do haveComplex64
forComplex<f64>
so that numbers are constructed withIn other scientific languages and platforms, developers typically appreciate ergonomic features[^1] reflecting special status of complex numbers. Improving ergonomic for complex numbers in Qiskit is a worthwhile task.
In this PR, I chose to continue using the definition of
const fn 64
that was introduced in #12459 https://github.com/Qiskit/qiskit/blob/1ed5951a98b594808525c8428e06178c160cfcbb/crates/circuit/src/gate_matrix.rs#L19-L22. I have moved the definition to a more neutral location and used it uniformly in all crates.I chose this in part to try to make this appealing to Qiskit devs. However there are choices.
c64
(referenced above). Can be used instatic
andconst
constructs. Requiresf64
arguments.c64
introduced recently innum-complex
. This creates a newComplex<f64>
from arguments that can convertInto<f64>
. For examplec64(1.0, 2.0)
andc64(1, 2)
.static
andconst
not supported, which is a major disadvantage for Qiskit.c64
slightly more generally so thatc64(1, 2.0)
is allowed (The version in item 2. does not support this.). This is a minor tweak to the implementation. However,static
andconst
are still not supported.c64!
is the most capable and flexible. This is functionally nearly the same as item 3. with the major advantage thatstatic
andconst
are supported.One might argue that having
c64(1, 2)
(orc64!(1, 2)
) return aComplex64
goes against the spirit of Rust. But I find decimal points that exist only to satisfy language semantics irksome and distracting. For rapid development, allowing more flexibility within constraints of semantics is useful. It would be better thatc64(1, 2)
construct a complex number with integer types in combination with facilities mix complex types. But Rust in general is too explicit for this.However, examining this PR, you can see that the number of superfluous decimal points is actually rather small at least so far. So retaining choice
1
is not a big burden.Constants for common complex and
f64
valuesThese are
const
bindings for very common complex values, such asC_ONE
,C_ZERO
etc. I think justONE
andZERO
are just as good, a bit less explicit, but neater and more readable (@sbrandhsn). These make source more readable and less cluttered, and likely less error prone. A couple of commonf64
values that are defined repeatedly locally have been moved to a common location. (@ShellyGarion @alexanderivrii)Type definitions for arrays representing gates
For example
GateArray1Q = [[Complex64; 2]; 2];
. Advantages are reducing clutter, signalling intent, etc.One could object to this and the previous item. These are less explicit and one might mistakenly assume that an identifier is bound to a different value. But these are generic objections to binding an identifier to a value. The statements of the objections are always true. Yet we find these refactorings sometimes worthwhile.
Relation to other PRs
The other part of #12507, which implements a gate, will be included in a separate PR.
[^1]: In Python the suffix
j
is recognized by the parser, so2j
represents the complex value(0.0, 2.0)
.