Skip to main content
IBM Quantum Platform

Note di rilascio di Qiskit 0.14

0.14.0

Terra 0.11.0

Preludio

La release 0.11.0 include diverse nuove funzionalità e correzioni di bug. Il cambiamento più importante di questa versione è l'aggiunta dello schedulatore di impulsi. Ciò consente agli utenti di definire il proprio programma quantistico come QuantumCircuit e quindi di mapparlo sulle istruzioni a impulsi sottostanti che controlleranno l'hardware quantistico per implementare il circuito.

Nuove funzioni

  • Aggiunti 5 nuovi comandi per recuperare facilmente i dati specifici dell'utente da BackendProperties: gate_property, gate_error, gate_length, qubit_property, t1, t2, readout_error e frequency. Restituiscono i valori specifici delle proprietà del backend. Ad esempio:

    from qiskit.test.mock import FakeOurense
backend = FakeOurense()
properties = backend.properties()

gate_property = properties.gate_property('u1')
gate_error = properties.gate_error('u1', 0)
gate_length = properties.gate_length('u1', 0)
qubit_0_property = properties.qubit_property(0)
t1_time_0 = properties.t1(0)
t2_time_0 = properties.t2(0)
readout_error_0 = properties.readout_error(0)
frequency_0 = properties.frequency(0)

  • Aggiunto il metodo Instruction.is_parameterized() per verificare se un oggetto istruzione è parametrizzato. Questo metodo restituisce True se e solo se l'istruzione ha un oggetto ParameterExpression o Parameter come uno dei suoi parametri.

  • Aggiunto un nuovo passaggio di analisi Layout2qDistance. Questo passaggio consente di "segnare" una selezione di layout, una volta impostato property_set['layout'] . Il punteggio sarà la somma delle distanze per ogni porta a due equbit del circuito, quando non sono direttamente collegate. Questo punteggio non tiene conto della direzione nella mappa di accoppiamento. Più basso è il numero, migliore è la selezione del layout.

    Ad esempio, si consideri una mappa di accoppiamento lineare [0]--[2]--[1] e il seguente circuito:

    qr = QuantumRegister(2, 'qr')
circuit = QuantumCircuit(qr)
circuit.cx(qr[0], qr[1])

    Se il layout è {qr[0]:0, qr[1]:1}, Layout2qDistance imposterà property_set['layout_score'] = 1. Se il layout è {qr[0]:0, qr[1]:2}, il risultato è property_set['layout_score'] = 0. Più basso è il punteggio, meglio è.

  • Aggiunto qiskit.QuantumCircuit.cnot come alias per il metodo cx di QuantumCircuit. I nomi cnot e cx sono spesso usati in modo intercambiabile, ora il metodo cx può essere chiamato con entrambi i nomi.

  • Aggiunto qiskit.QuantumCircuit.toffoli come alias per il metodo ccx di QuantumCircuit. I nomi toffoli e ccx sono spesso usati in modo intercambiabile, ora il metodo ccx può essere chiamato con entrambi i nomi.

  • Aggiunto qiskit.QuantumCircuit.fredkin come alias per il metodo cswap di QuantumCircuit. I nomi fredkin e cswap sono spesso usati in modo intercambiabile, ora il metodo cswap può essere chiamato con entrambi i nomi.

  • La modalità di uscita latex per qiskit.visualization.circuit_drawer() e il metodo qiskit.circuit.QuantumCircuit.draw() hanno ora una modalità per passare il latex grezzo dalle etichette e dai parametri del gate. La sintassi per farlo rispecchia quella della modalità mathtext di matplotlib. Qualsiasi porzione di una stringa di etichetta compresa tra una coppia di caratteri '$' sarà trattata come latex grezzo e passata direttamente nel latex di output generato. Questo può essere sfruttato per aggiungere una formattazione più avanzata agli schemi circuitali generati con il cassetto Latex.

    Prima di questa versione, tutte le etichette dei gate venivano sottoposte a una conversione utf8 -> latex per assicurarsi che il latex di uscita compilasse la stringa come previsto. Questo è ancora ciò che accade per tutte le porzioni di un'etichetta al di fuori della coppia '$'. Inoltre, se si desidera utilizzare un segno di dollaro nell'etichetta, assicurarsi di eseguire l'escape nella stringa dell'etichetta (ad esempio '\$').

    È possibile combinare questo passaggio con la conversione utf8 -> latex per creare l'etichetta esatta desiderata, ad esempio:

    from qiskit import circuit
circ = circuit.QuantumCircuit(2)
circ.h([0, 1])
circ.append(circuit.Gate(name='α_gate', num_qubits=1, params=[0]), [0])
circ.append(circuit.Gate(name='α_gate$_2$', num_qubits=1, params=[0]), [1])
circ.append(circuit.Gate(name='\$α\$_gate', num_qubits=1, params=[0]), [1])
circ.draw(output='latex')

    l'etichetta del primo cancello personalizzato sarà α_gate, il secondo sarà α_gate con un pedice 2 e l'etichetta dell'ultimo cancello personalizzato sarà $α$_gate.

  • Aggiungere la classe ControlledGate per rappresentare i cancelli controllati. Le istanze di cancelli controllati vengono create con il metodo control(n) degli oggetti Gate , dove n rappresenta il numero di controlli. I qubit di controllo vengono prima dei qubit controllati nel nuovo gate. Ad esempio:

    from qiskit import QuantumCircuit
from qiskit.extensions import HGate
hgate = HGate()
circ = QuantumCircuit(4)
circ.append(hgate.control(3), [0, 1, 2, 3])
print(circ)

    genera:

    q_0: |0>──■──
          │
q_1: |0>──■──
          │
q_2: |0>──■──
        ┌─┴─┐
q_3: |0>┤ H ├
        └───┘

  • I valori consentiti dei parametri e dei campi di meas_level possono ora essere un membro della classe IntEnum qiskit.qobj.utils.MeasLevel. Può essere utilizzato quando si chiama execute (o qualsiasi altro punto in cui è specificato meas_level ) con un esperimento a impulsi. Ad esempio:

    from qiskit import QuantumCircuit, transpile, schedule, execute
from qiskit.test.mock import FakeOpenPulse2Q
from qiskit.qobj.utils import MeasLevel, MeasReturnType

backend = FakeOpenPulse2Q()
qc = QuantumCircuit(2, 2)
qc.h(0)
qc.cx(0,1)
qc_transpiled = transpile(qc, backend)
sched = schedule(qc_transpiled, backend)
execute(sched, backend, meas_level=MeasLevel.CLASSIFIED)

    In questo esempio, meas_level=MeasLevel.CLASSIFIED e meas_level=2 possono essere usati indifferentemente.

  • È incluso un nuovo selettore di layout basato sulla risoluzione dei vincoli. CSPLayout modella il problema di trovare un layout come un problema di vincoli e utilizza il backtracking ricorsivo per risolverlo.

    cmap16 = CouplingMap(FakeRueschlikon().configuration().coupling_map)

qr = QuantumRegister(5, 'q')
circuit = QuantumCircuit(qr)
circuit.cx(qr[0], qr[1])
circuit.cx(qr[0], qr[2])
circuit.cx(qr[0], qr[3])

pm = PassManager(CSPLayout(cmap16))
circuit_after = pm.run(circuit)
print(pm.property_set['layout'])
    Layout({
1: Qubit(QuantumRegister(5, 'q'), 1),
2: Qubit(QuantumRegister(5, 'q'), 0),
3: Qubit(QuantumRegister(5, 'q'), 3),
4: Qubit(QuantumRegister(5, 'q'), 4),
15: Qubit(QuantumRegister(5, 'q'), 2)
})

    Il parametro CSPLayout(...,strict_direction=True) è più restrittivo, ma garantisce che non sia necessario eseguire CXDirection dopo.

    pm = PassManager(CSPLayout(cmap16, strict_direction=True))
circuit_after = pm.run(circuit)
print(pm.property_set['layout'])
    Layout({
8: Qubit(QuantumRegister(5, 'q'), 4),
11: Qubit(QuantumRegister(5, 'q'), 3),
5: Qubit(QuantumRegister(5, 'q'), 1),
6: Qubit(QuantumRegister(5, 'q'), 0),
7: Qubit(QuantumRegister(5, 'q'), 2)
})

    Se il sistema di vincoli non è risolvibile, la proprietà di layout non viene impostata.

    circuit.cx(qr[0], qr[4])
pm = PassManager(CSPLayout(cmap16))
circuit_after = pm.run(circuit)
print(pm.property_set['layout'])
    None

  • PulseBackendConfiguration (a cui si accede normalmente come backend.configuration ()) è stato esteso con metodi utili per esplorare i suoi dati e le funzionalità esistenti in PulseChannelSpec. PulseChannelSpec sarà deprecato in futuro. Ad esempio:

    backend = provider.get_backend(backend_name)
config = backend.configuration()
q0_drive = config.drive(0)  # or, DriveChannel(0)
q0_meas = config.measure(0)  # MeasureChannel(0)
q0_acquire = config.acquire(0)  # AcquireChannel(0)
config.hamiltonian  # Returns a dictionary with hamiltonian info
config.sample_rate()  # New method which returns 1 / dt

  • PulseDefaults (a cui si accede normalmente come backend.defaults()) ha un attributo, circuit_instruction_map che ha i metodi di CmdDef. Il nuovo circuit_instruction_map è un oggetto di InstructionScheduleMap con tre nuove funzioni, oltre a quella che aveva CmdDef :

    • qubit_instructions(qubits) restituisce le operazioni definite per i qubit
    • assert_has(istruzione, qubit) solleva un errore se l'operazione non è definita
    • remove(istruzione, qubit) come pop, ma non richiede parametri

    Ci sono alcune differenze rispetto al CmdDef:

    • __init__ non accetta argomenti
    • cmds e cmd_qubits sono deprecati e sostituiti con instructions e qubits_with_instruction

    Esempio:

    backend = provider.get_backend(backend_name)
inst_map = backend.defaults().circuit_instruction_map
qubit = inst_map.qubits_with_instruction('u3')[0]
x_gate = inst_map.get('u3', qubit, P0=np.pi, P1=0, P2=np.pi)
pulse_schedule = x_gate(DriveChannel(qubit))

  • Alla funzione qiskit.visualization.pulse_drawer() e al metodo qiskit.pulse.Schedule.draw() è stato aggiunto un nuovo parametro kwarg, show_framechange_channels , che consente di disabilitare la visualizzazione dei canali con le sole istruzioni framechange nelle visualizzazioni degli impulsi. Quando questo nuovo kwarg è impostato su False , la visualizzazione della programmazione degli impulsi in uscita non includerà i canali che includono solo le modifiche dei fotogrammi.

    Ad esempio:

    from qiskit.pulse import *
from qiskit.pulse import library as pulse_lib

gp0 = pulse_lib.gaussian(duration=20, amp=1.0, sigma=1.0)
sched = Schedule()
channel_a = DriveChannel(0)
channel_b = DriveChannel(1)
sched += Play(gp0, channel_a)
sched = sched.insert(60, ShiftPhase(-1.57, channel_a))
sched = sched.insert(30, ShiftPhase(-1.50, channel_b))
sched = sched.insert(70, ShiftPhase(1.50, channel_b))

sched.draw(show_framechange_channels=False)

  • Viene aggiunta una nuova funzione di utilità qiskit.result.marginal_counts() che consente la marginalizzazione dei conteggi su alcuni indici di interesse. Ciò è utile quando si misura un numero di qubit superiore al necessario e si desidera ottenere i conteggi delle osservazioni solo per un sottoinsieme di essi.

  • Quando passmanager.run(...) viene invocato con più di un circuito, la transpilazione di questi circuiti viene eseguita in parallelo.

  • PassManagers può ora essere tagliato per creare un nuovo PassManager contenente un sottoinsieme di passaggi, utilizzando l'operatore di parentesi quadra. Ciò consente di eseguire o disegnare una parte del sito PassManager per facilitare i test e la visualizzazione. Ad esempio, proviamo a disegnare le prime 3 passate di una pm PassManager, oppure eseguiamo solo la seconda passata sul nostro circuito:

    pm[0:4].draw()
circuit2 = pm[1].run(circuit)

    Inoltre, PassManagers può essere creato aggiungendo due PassManagers o aggiungendo direttamente un passaggio/una lista di passaggi a una PassManager.

    pm = pm1[0] + pm2[1:3]
pm += [setLayout, unroller]

  • A Qiskit è stato aggiunto un modulo di base scheduler . Lo scheduler programma un input transpiled QuantumCircuit in un impulso Schedule. Lo scheduler accetta come input un Schedule e un Backend impulso, oppure un CmdDef che mette in relazione gli oggetti Instruction circuito su qubit specifici con gli impulsi Scheduler e un meas_map che determina quali misure devono avvenire insieme.

    Esempio di programmazione:

    from qiskit import QuantumCircuit, transpile, schedule
from qiskit.test.mock import FakeOpenPulse2Q

backend = FakeOpenPulse2Q()
qc = QuantumCircuit(2, 2)
qc.h(0)
qc.cx(0,1)
qc_transpiled = transpile(qc, backend)
schedule(qc_transpiled, backend)

    alap``asapLo scheduler supporta attualmente due politiche di scheduling, as\late\code(01) e as\soon\code(01), che programmano rispettivamente le istruzioni a impulsi in modo che avvengano il più tardi possibile o il più presto possibile tra i qubit di un circuito. La politica di programmazione può essere selezionata con l'argomento di ingresso method, ad esempio:

    schedule(qc_transpiled, backend, method='alap')

    È facile utilizzare un impulso Schedule all'interno di un QuantumCircuit mappandolo su un'istruzione di circuito personalizzata, come una porta che può essere utilizzata in un QuantumCircuit. Per farlo, occorre innanzitutto definire il gate personalizzato e poi aggiungere una voce nel sito CmdDef per il gate, per ogni qubit a cui il gate sarà applicato. Il gate può essere utilizzato nel sito QuantumCircuit. Al momento della programmazione, il gate viene mappato sul programma di impulsi sottostante. L'utilizzo di questa tecnica consente una facile integrazione con i moduli qiskit preesistenti, come Ignis.

    Ad esempio:

    from qiskit import pulse, circuit, schedule
from qiskit.pulse import pulse_lib

custom_cmd_def = pulse.CmdDef()

# create custom gate
custom_gate = circuit.Gate(name='custom_gate', num_qubits=1, params=[])

# define schedule for custom gate
custom_schedule = pulse.Schedule()
custom_schedule += pulse_lib.gaussian(20, 1.0, 10)(pulse.DriveChannel)

# add schedule to custom gate with same name
custom_cmd_def.add('custom_gate', (0,), custom_schedule)

# use custom gate in a circuit
custom_qc = circuit.QuantumCircuit(1)
custom_qc.append(custom_gate, qargs=[0])

# schedule the custom gate
schedule(custom_qc, cmd_def=custom_cmd_def, meas_map=[[0]])

Problemi noti

  • La funzione di transpiling in parallelo quando passmanager.run(...) viene invocato con più di un circuito non è supportata in Windows. Per maggiori dettagli, vedere il numero 2988.

Note sull'aggiornamento

  • La classe qiskit.pulse.channels.SystemTopology è stata utilizzata come classe ausiliaria per PulseChannelSpec. È stato rimosso con la deprecazione di PulseChannelSpec e le modifiche a BackendConfiguration lo rendono inutile.
  • La rappresentazione dei qubit e dei bit classici come tuple, precedentemente deprecata nella versione 0.9, è stata rimossa. L'uso degli oggetti Qubit e Clbit è il nuovo modo di rappresentare i qubit e i bit classici.
  • La rappresentazione precedentemente deprecata dell'insieme di basi come singola stringa è stata rimossa. Un elenco di stringhe è il nuovo modo preferito.
  • Il metodo BaseModel.as_dict, deprecato nella release 0.9, è stato rimosso in favore del metodo BaseModel.to_dict.
  • In PulseDefaults (a cui si accede normalmente come backend.defaults ()), qubit_freq_est e meas_freq_est vengono ora restituiti in Hz anziché in GHz. Ciò significa che i nuovi valori di ritorno sono 1e9 * il loro valore precedente.
  • l' aneto è stato aggiunto come requisito. Questo è necessario per consentire il funzionamento di passmanager.run() in parallelo per più di un circuito.
  • Il gate UBase, precedentemente deprecato nella release 0.9, è stato rimosso. Al suo posto va utilizzato il cancello U3Gate .
  • Il gate CXBase, precedentemente deprecato nella release 0.9, è stato rimosso. Al suo posto va utilizzato il cancello CnotGate .
  • L'istruzione snapshot è utilizzata per convertire implicitamente il parametro label in stringa. Questa conversione è stata rimossa e viene sollevato un errore se non viene fornita una stringa.
  • Il gate U0Gate, precedentemente deprecato nella release 0.9, è stato rimosso. Per inserire i ritardi si dovrebbe invece utilizzare il gate IdGate .

Note di deprecazione

  • La classe qiskit.pulse.CmdDef è stata deprecata. Si dovrebbe invece utilizzare il sito qiskit.pulse.InstructionScheduleMap. L'oggetto InstructionScheduleMap per un sistema abilitato agli impulsi è accessibile all'indirizzo backend.defaults().instruction_schedules.

  • PulseChannelSpec è stato deprecato. Utilizzare invece BackendConfiguration . La configurazione del backend è accessibile normalmente come backend.configuration(). Il config è stato esteso con la maggior parte delle funzionalità di PulseChannelSpec, con alcune modifiche, come segue, dove 0 è un indice di qubit esemplare:

    pulse_spec.drives[0]   -> config.drive(0)
pulse_spec.measures[0] -> config.measure(0)
pulse_spec.acquires[0] -> config.acquire(0)
pulse_spec.controls[0] -> config.control(0)

    Ora, se si tenta di ottenere un canale per un qubit che non esiste per il dispositivo, verrà sollevato un BackendConfigurationError con una spiegazione utile.

    I metodi memoryslots e registerslots di PulseChannelSpec non sono stati migrati nella configurazione del backend. Queste risorse classiche non sono limitate dalla configurazione fisica di un sistema backend. Si prega di istanziarli direttamente:

    pulse_spec.memoryslots[0] -> MemorySlot(0)
pulse_spec.registerslots[0] -> RegisterSlot(0)

    Il metodo qubits non è migrato nella configurazione del backend. Il risultato di qubits può essere costruito come tale:

    [q for q in range(backend.configuration().n_qubits)]

  • Qubit all'interno di pulse.channels è stato deprecato. Non devono essere utilizzati. È possibile ottenere le mappature dei qubit del canale <=> attraverso il programma BackendConfiguration (o backend.configuration ()).

  • La funzione qiskit.visualization.circuit_drawer.qx_color_scheme() è stata deprecata. Questa funzione non è più utilizzata internamente e non riflette lo stile attuale di IBM QX. Se si utilizza questa funzione per generare un dizionario di stile in locale, è necessario salvare l'output e utilizzare direttamente il dizionario.

  • L'eccezione TranspilerAccessError è stata deprecata. È possibile utilizzare una funzione alternativa TranspilerError per ottenere la stessa funzionalità. Questa funzione alternativa fornisce la stessa identica funzionalità, ma con una maggiore generalità.

  • I buffer in Pulse sono deprecati. Se viene fornito un buffer non nullo, viene emesso un avviso che ricorda di utilizzare un ritardo. Altre opzioni possono essere l'aggiunta di campioni a un'istruzione di impulso che sono ( 0.+0.j ) o l'impostazione del tempo di inizio dell'impulso successivo a schedule.duration + buffer.

  • Il passaggio dei tipi sympy.Basic, sympy.Expr e sympy.Matrix come parametri di istruzione è deprecato e sarà rimosso in una versione futura. È necessario convertire l'input in uno dei tipi supportati, che sono:

    • int
    • float
    • complex
    • str
    • np.ndarray

Correzioni di bug

  • I passaggi Collect2qBlocks e CommutationAnalysis del transpiler non erano in grado di elaborare i circuiti contenenti porte parametrizzate, impedendo la trasposizione dei circuiti parametrizzati al livello di ottimizzazione 2 o superiore. Questi passaggi sono stati corretti per trattare le porte parametrizzate come opache.
  • La funzione align_measures presentava un problema a causa del quale gli impulsi di stimolo Measure non venivano allineati correttamente con gli impulsi Acquire, generando un errore. Il problema è stato risolto.
  • L'uso di numpy.random.seed è stato rimosso, in modo che le chiamate alle funzioni di qiskit non influenzino i risultati delle future chiamate a numpy.random
  • Corretta la condizione di race condition che si verifica nel job monitor quando job.queue_position() restituisce None. None è un ritorno valido da job.queue_position().
  • Il supporto del backend per memory=True ora viene controllato quando viene passato il kwarg. QiskitError risultati se non supportati.
  • Quando si effettuava la transpilazione senza mappa di accoppiamento, non si controllava la quantità di qubit del circuito da transpilare. Ora il processo di transpile controlla che il backend abbia abbastanza qubit per allocare il circuito.

Altre note

  • La funzione qiskit.result.marginal_counts() sostituisce una funzione di utilità simile presente in qiskit-ignis qiskit.ignis.verification.tomography.marginal_counts(), che sarà deprecata in una futura versione di qiskit-ignis.
  • Tutti i tipi di output dei parametri sympy sono stati rimossi (o deprecati, come indicato) da qiskit-terra. Ciò include i parametri di tipo sympy negli oggetti QuantumCircuit , nei nodi qasm ast o negli oggetti Qobj .

Aer 0.3

Nessuna modifica

Ignis 0.2

Nessuna modifica

Acqua 0.6

Nessuna modifica

IBM Q Fornitore 0.4

Preludio

La versione 0.4.0 è la prima che utilizza tutte le funzionalità della nuova API IBM Q. In particolare, la classe IBMQJob è stata rinnovata per poter recuperare più informazioni da IBM Q, ed è stata aggiunta una classe Job Manager per consentire un utilizzo di livello superiore e più fluido di lavori grandi o complessi. Se non avete ancora effettuato l'aggiornamento dalla versione precedente IBM Q Experience o QConsole, consultate le note di rilascio di IBM Q Provider 0.3 (Qiskit 0.11 ) per maggiori dettagli su come effettuare la transizione. Gli account legacy non saranno più supportati a partire da questa release.

Nuove funzioni

Modifiche al lavoro

La classe IBMQJob è stata rivista e ora riproduce più fedelmente il contenuto di un lavoro remoto, oltre a nuove funzionalità:

  • È ora possibile assegnare un nome a un lavoro, specificando IBMQBackend.run(..., job_name='...') quando si invia un lavoro. Questo nome può essere recuperato tramite IBMQJob.name() e può essere utilizzato per il filtraggio.
  • I lavori possono ora essere condivisi con altri utenti a diversi livelli (globale, per hub, gruppo o progetto) tramite un parametro opzionale job_share_level quando si invia il lavoro.
  • IBMQJob hanno ora più attributi, che riflettono i contenuti dei lavori remoti IBM Q. Ciò implica che i nuovi attributi introdotti dall'API IBM Q saranno automaticamente e immediatamente disponibili per l'uso (ad esempio, job.new_api_attribute). I nuovi attributi saranno promossi a metodi quando saranno considerati stabili (ad esempio, job.name()).
  • .error_message() restituisce ulteriori informazioni sul motivo del fallimento di un lavoro.
  • .queue_position() accetta un parametro refresh per forzare un aggiornamento.
  • .result() accetta un parametro opzionale partial , per restituire eventuali risultati parziali di lavori non riusciti. Si tenga presente che i metodi di Result , come get_counts() , solleveranno un'eccezione se applicati a esperimenti non riusciti.

Si noti che i cambiamenti includono alcune modifiche di basso livello della classe. Se le istanze sono state create manualmente, si noti che:

  • la firma del costruttore è stata modificata per tenere conto delle nuove caratteristiche.
  • il metodo .submit() non può più essere chiamato direttamente e si prevede che i lavori vengano inviati tramite il metodo sincrono IBMQBackend.run() o tramite il Job Manager.
Gestore lavoro

È stato introdotto un nuovo Job Manager (IBMQJobManager), come meccanismo di livello superiore per la gestione di lavori composti da più circuiti o programmi a impulsi. Il Job Manager mira a fornire un'interfaccia trasparente, suddividendo in modo intelligente l'input in unità di lavoro efficienti e sfruttando appieno i diversi componenti. Sarà ampliato nelle prossime versioni e diventerà il punto di ingresso consigliato per la presentazione dei lavori.

Il metodo .run() riceve un elenco di circuiti o programmi di impulsi e restituisce un ManagedJobSet instance, che può essere utilizzato per tenere traccia degli stati e dei risultati di questi lavori. Ad esempio:

from qiskit.providers.ibmq.managed import IBMQJobManager
from qiskit.circuit.random import random_circuit
from qiskit import IBMQ
from qiskit.compiler import transpile

provider = IBMQ.load_account()
backend = provider.backends.ibmq_ourense

circs = []
for _ in range(1000000):
    circs.append(random_circuit(2, 2))
transpile(circs, backend=backend)

# Farm out the jobs.
jm = IBMQJobManager()
job_set = jm.run(circs, backend=backend, name='foo')

job_set.statuses()    # Gives a list of job statuses
job_set.report()    # Prints detailed job information
results = job_set.results()
counts = results.get_counts(5)   # Returns data for experiment 5
provider.backends modifiche

Il membro provider.backends , che in precedenza era una funzione che restituiva un elenco di backend, è stato promosso a servizio. Questo implica che può essere usato sia nel modo precedente, come metodo .backends() , sia come attributo .backends con funzionalità ampliate:

  • contiene i backend esistenti di quel provider come attributi, che possono essere usati per il completamento automatico. Ad esempio:

    my_backend = provider.get_backend('ibmq_qasm_simulator')

    Š equivalente a:

    my_backend = provider.backends.ibmq_qasm_simulator

  • i metodi provider.backends.jobs() e provider.backends.retrieve_job() possono essere utilizzati per recuperare i lavori a livello di provider.

Altre modifiche
  • La funzione backend.properties() accetta ora un parametro opzionale datetime . Se specificato, la funzione restituisce le proprietà del backend più vicine, ma più vecchie, del filtro datetime specificato.
  • Alcuni warnings sono stati ridotti a messaggi logger.warning .
Questa pagina è stata utile?
Segnala un bug, un errore di battitura o richiedi contenuti su GitHub.