Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Docstring for QuditProcessorSpec has mistake for "availability" #400

Open
rileyjmurray opened this issue Feb 7, 2024 · 2 comments
Open
Assignees
Labels
bug A bug or regression
Milestone

Comments

@rileyjmurray
Copy link
Collaborator

rileyjmurray commented Feb 7, 2024

Describe the bug
The docstring for QuditProcessorSpec has a mistake for the "availability" keyword argument. The existing code is ...

availability : dict, optional
A dictionary whose keys are some subset of the keys (which are gate names) `nonstd_gate_unitaries` and the
strings (which are gate names) in `gate_names` and whose values are lists of qubit-label-tuples. Each
qubit-label-tuple must have length equal to the number of qubits the corresponding gate acts upon, and
causes that gate to be available to act on the specified qubits. Instead of a list of tuples, values of
`availability` may take the special values `"all-permutations"` and `"all-combinations"`, which as their
names imply, equate to all possible permutations and combinations of the appropriate number of qubit labels
(deterined by the gate's dimension). If a gate name is not present in `availability`, the default is
`"all-permutations"`. So, the availability of a gate only needs to be specified when it cannot act in every
valid way on the qubits (e.g., the device does not have all-to-all connectivity).

The relevant substring in the docstring is

   If a gate name is not present in `availability`, the default is `"all-permutations"`.  So, the availability of a gate
   only needs to be specified when it cannot act in every valid way on the qubits (e.g., the device does not have
   all-to-all connectivity).

I'm not sure what the actual behavior is, but I've given code below which shows that the behavior is different from the docstring.

To Reproduce

import numpy as np
import pygsti as pg
from pygsti.processors import QuditProcessorSpec
from pygsti.models import create_explicit_model
import scipy

gate_names=['Gxpi2', 'Gypi2']
Uxpi2 = np.asarray(np.bmat([[scipy.linalg.expm(-1j/2 * np.pi/2 * pg.sigmax),np.zeros((2,1))],
                 [np.zeros((1,2)),np.array([[1]])]]))
Uypi2 = np.asarray(np.bmat([[scipy.linalg.expm(-1j/2 * np.pi/2 * pg.sigmay),np.zeros((2,1))],
                 [np.zeros((1,2)),np.array([[1]])]]))

qps = QuditProcessorSpec(
    qudit_labels=[0], 
    qudit_udims=[3],
    gate_names=['Gxpi2', 'Gypi2'],
    nonstd_gate_unitaries={'Gxpi2':Uxpi2,'Gypi2':Uypi2}
    #,availability={'Gxpi2':[0], 'Gypi2':[0]} 
)
# the next line errors if (and only if) you keep the "availability" keyword arg commented out
model = create_explicit_model(qps,  ideal_spam_type='full pure',  ideal_gate_type='full TP', basis='gm')

Expected behavior
The behavior described in the docstring.

@rileyjmurray rileyjmurray added the bug A bug or regression label Feb 7, 2024
@coreyostrove coreyostrove added this to the 0.9.13 milestone Feb 13, 2024
@sserita sserita modified the milestones: 0.9.13, 0.9.12.2 Mar 26, 2024
@sserita
Copy link
Contributor

sserita commented Apr 2, 2024

@rileyjmurray What version of pyGSTi were you running this on? I'm trying to reproduce on current develop and failing to do so (both commenting/uncommenting the availability line succeed).

@sserita sserita modified the milestones: 0.9.12.2, 0.9.13 Apr 15, 2024
@rileyjmurray
Copy link
Collaborator Author

Sorry for the slow response, @sserita.

I used a permalink to the version of the code I was running. It points to a specific commit on develop. Here's a permalink to the state of the whole pyGSTi repo at the relevant commit https://github.com/sandialabs/pyGSTi/tree/690542693c4fe23afb1d7995058660ed9e989457.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A bug or regression
Projects
None yet
Development

No branches or pull requests

3 participants