QPYシリアライゼーション

qiskit.qpy

QPYはオブジェクトのバイナリ・シリアライゼーション・フォーマットです。 QuantumCircuit オブジェクトのバイナリ・シリアライゼーション・フォーマットで、クロスプラットフォーム、 Python バージョン非依存、将来的な下位互換性を持つように設計されています。 をシステム間で保存またはコピーするメカニズムが必要な場合は、QPYを使用する必要があります。 QuantumCircuit Qiskitコード外で定義されたカスタム属性を除く）完全なQiskitオブジェクト構造を保持する。 のような他のシリアライズ形式とは異なります。 OpenQASM ( 2.0 または 3.0 ) のような抽象化モデルが異なり、元の回路に含まれる情報が失われる可能性があります（またはQiskitオブジェクトのいくつかの側面を表現できません）。また、 Python 's pickleは Qiskitオブジェクトを正確に保持しますが、単一のQiskitバージョンでしか動作しません（また、 潜在的に安全ではありません）。

基本的な使用法

QPYの使用は簡単で、 Python の標準ライブラリである pickle と json のシリアライザのユーザーAPIをミラーするように定義されています。 2つのユーザー向け機能がある： qiskit.qpy.dump() と qiskit.qpy.load() であり、それぞれQPYデータをファイル・オブジェクトにダンプし、ファイル・オブジェクト内のQPYデータから回路をロードするために使用される。 例:

from qiskit.circuit import QuantumCircuit
from qiskit import qpy

qc = QuantumCircuit(2, name='Bell', metadata={'test': True})
qc.h(0)
qc.cx(0, 1)
qc.measure_all()

with open('bell.qpy', 'wb') as fd:
    qpy.dump(qc, fd)

with open('bell.qpy', 'rb') as fd:
    new_qc = qpy.load(fd)[0]

また qiskit.qpy.dump() 関数を使えば、1つのQPYファイルに複数の回路を含めることもできる：

with open('twenty_bells.qpy', 'wb') as fd:
    qpy.dump([qc] * 20, fd)

そのファイルをロードすると、すべての回路を含むリストが返される

with open('twenty_bells.qpy', 'rb') as fd:
    twenty_new_bells = qpy.load(fd)

API の資料

load

from qiskit import qpy

with open('bell.qpy', 'rb') as fd:
    circuits = qpy.load(fd)

import gzip
from qiskit import qpy

with gzip.open('bell.qpy.gz', 'rb') as fd:
    circuits = qpy.load(fd)

dump

from qiskit.circuit import QuantumCircuit
from qiskit import qpy

qc = QuantumCircuit(2, name='Bell', metadata={'test': True})
qc.h(0)
qc.cx(0, 1)
qc.measure_all()

with open('bell.qpy', 'wb') as fd:
    qpy.dump(qc, fd)

import gzip

with gzip.open('bell.qpy.gz', 'wb') as fd:
    qpy.dump(qc, fd)

get_qpy_version

from qiskit import qpy

qpy_version = qpy.get_qpy_version(qpy_file)
if qpy_version > 12:
    qpy.load(qpy_file)

これらの関数は QiskitError を発生させます。

QpyError

シリアライズのターゲット QPY バージョンが最大値よりも低く設定されているにもかかわらず、シリアライズされるオブジェクトにそのフォーマットでは表現できない機能が含まれている場合、QPY のサブクラスである QpyError が発生します：

UnsupportedFeatureForVersion

qiskit.qpy.QPY_VERSION

qiskit.qpy.QPY_COMPATIBILITY_VERSION

QPY互換性

QPYフォーマットは、今後も下位互換性を保つように設計されている。 つまり、QPYを生成したバージョンよりも新しいQiskitバージョンでQPYをロードできるはずです。 ただし、古いバージョンのQiskitでQPYファイルを読み込むことはサポートされておらず、動作しない可能性があります。

たとえば、qiskit-terra 0.18.1 を使用して QPY ファイルを生成した場合、その QPY ファイルを qiskit-terra 0.19.0 および仮想 qiskit-terra 0.29.0 でロードできます。 しかし、そのQPYファイルを 0.18.0。

回路のメタデータやカスタム Annotation オブジェクトは、オブジェクト自体が完全にユーザー定義であるため、ユーザーが指定したクラスによってシリアル化およびデシリアル化されることに注意してください。したがって、これらの前方互換性および後方互換性は、ユーザーが提供する内容によって制限されます。

読み込まれる機能が対応するqiskitリリースで非推奨である場合、QPYは非推奨期間とその機能が内部的にどのように扱われるかを知らせる QPYLoadingDeprecatedFeatureWarning を発生させ、非推奨期間とその機能が内部的にどのように扱われるかを通知します。

QPYLoadingDeprecatedFeatureWarning

QPYフォーマットのバージョン履歴

異なるQiskitバージョン間でQPYファイルをロードすることを計画している場合、特定のリリースで利用可能だったバージョンを知っていると便利です。 QPYは後方互換性がありますが、前方互換性はないので、あるQPYフォーマットのバージョンが、あなたが呼び出そうとしているリリースでリリースされたものであることを確認する必要があります。 load() を使う必要がある。 以下の表は、qiskit-terra 0.18.0 でのQPYの導入に遡り、すべてのQiskit（およびQiskit 1.0.0 より前のqiskit-terra）リリースでサポートされたQPYバージョンの一覧です。

QPY形式

QPYシリアライゼーションフォーマットは、Qiskitオブジェクトのための移植可能なクロスプラットフォームのバイナリシリアライゼーションフォーマットです。 QuantumCircuit バイナリシリアライズフォーマットです。 基本的なファイル形式は以下の通り：

QPYファイル（またはメモリー・オブジェクト）は、常に次の6バイトの UTF8 文字列で始まります： QISKIT 、その直後にファイル全体のヘッダーが続きます。 Cの構造体として定義されたファイル・ヘッダーの内容は以下の通りである：

struct {
    uint8_t qpy_version;
    uint8_t qiskit_major_version;
    uint8_t qiskit_minor_version;
    uint8_t qiskit_patch_version;
    uint64_t num_circuits;
}

V10 以降、ファイルヘッダ構造体に、記号式に使われるエンコード方式を表す新しいフィールドが追加される：

struct {
    uint8_t qpy_version;
    uint8_t qiskit_major_version;
    uint8_t qiskit_minor_version;
    uint8_t qiskit_patch_version;
    uint64_t num_circuits;
    char symbolic_encoding;
}

V16、ファイルヘッダ構造体の直後に、ファイル内の各回路ペイロードのバイトオフセットを含む回路開始テーブルが続く。 回路開始テーブルには num_circuits のエントリーがあり、それぞれのタイプは uint64_t である。 以前のすべてのバージョンでは、ファイルヘッダの直後に、間にパディングを挟むことなく、回路のペイロードが順番に続く。

すべての値は、クロスプラットフォームの互換性を確保するため、ネットワークバイト順 [1] （ビッグエンディアン）を使用しています。 ただし、QPY フォーマットのバージョン 17 以下の場合、整数および浮動小数点のエンコーディングはリトルエンディアンとなります INSTRUCTION_PARAM 。

個々の回路は、上から順に以下のパーツで構成されている：

HEADER
METADATA
REGISTERS
ANNOTATION_HEADER
STANDALONE_VARS
CUSTOM_DEFINITIONS
INSTRUCTIONS

バージョン QPY で変更: REGISTERS と STANDALONE_VARS の間に ANNOTATION_HEADER が追加された。

バージョンQPYでの変更点: 12 REGISTERS と CUSTOM_DEFINITIONS の間に STANDALONE_VARS が追加された。

各サーキットにはサーキットペイロードがある（総数はファイルヘッダの num_circuits ）。 データの回路間にパディングはない。

バージョン17

バージョン 17 では、演算子を含む SparseObservable シリアライズおよびデシリアライ PauliEvolutionGate ズのサポートが追加されました。

PAULI_EVOLUTIONの変更点

PAULI_EVOLUTION 自体の形式に変更はありませんが、パックされた進化ゲートの直後に続く演算子の形式が更新されました。 SparseObservableSPARSE_PAULI_OP_LIST_ELEM 形式で定義された operator_count 個の要素の代わりに、ペイロードでは各演算子の型を指定するようになり、これにより、型 SparsePauliOp または の演算子の両方を考慮できるようになりました。

PAULI_EVOLUTION に続く新しいペイロードには、bool ("!?") が operator_count 個並んだ後に、その演算子が続く形式が正確に含まれるようになった。 Truebool が の場合、その演算子は となり SparseObservable 、新しい SPARSE_OBSERVABLE 形式（後述）で解釈されます。 Falseその場合は、演算子は であり SparsePauliOp 、既存の SPARSE_PAULI_OP_LIST_ELEM 形式に従って解釈されます。

新しい SPARSE_OBSERVABLE

SparseObservableSPARSE_OBSERVABLE 形式は、次のように定義される のインスタンスを表します

struct {
  uint32_t num_qubits;
  uint64_t coeff_data_len;
  uint64_t bitterm_data_len;
  uint64_t inds_data_len;
  uint64_t bounds_data_len;
}

直後に量子ビットの数が続く。その後、係数、ビット項、インデックス、および観測量の境界値のデータ配列が続く。 このフォーマットは、各配列が占有するバイト数を指定します。 要素の数は、バイト数を各要素のサイズで割ることで計算できます。

• 各係数は、連続する2つの「!d」要素として格納される。最初に実部、次に虚部が続く。
• ビット項の要素は「!」型です「H」は、 u8 の値を表し、 SparseObservable.BitTerm
• インデックス要素の型は「!」です私。
• 境界要素は「!」型であるQ”.

バージョン16

バージョン16では、QPYファイルフォーマットにサーキットスタートテーブルが追加された。 ファイル内の各回路ペイロードのバイトオフセットのインデックスとなる。 この変更の動機は、QPYデシリアライザーの将来のRust実装において、マルチスレッドを使用した回路のより効率的なロードを可能にするためである。

DURATIONの変更

ピコ秒を表す既存のDURATION型エンコーディングに新しいバリアントが追加された。 これは以下のようにエンコードされ、これまでサポートされてきたバリアントに追加される。

バージョン15

バージョン15では、ペイロードフォーマットにカスタムアノテーションの概念が追加された。 QPY自身は、アノテーションがどのようにシリアライズまたはデシリアライズされるかを指定していません。 しかし、このフォーマットはサブシリアライザーと協調する。

バージョン15では、単一回線ペイロードのトップレベルにおいて、 STANDALONE_VARS と CUSTOM_DEFINITIONS フィールドの間に ANNOTATION_HEADER フィールドが追加されている。 これは、ABI互換の方法で INSTRUCTION 構造体の1つのフィールドの解釈を変更し、 INSTRUCTION ペイロードのセットビットを条件として存在する INSTRUCTION に INSTRUCTION_ANNOTATIONS トレーラを追加する。

新しい注釈ヘッダー

ANNOTATION_HEADER フィールドは、ヘッダー中の可変サイズのペイロードである。 Cの構造体である ANNOTATION_HEADER_STATIC のインスタンスで始まる：

struct ANNOTATION_HEADER_STATIC {
    uint32_t num_namespaces;
}

この直後に、 ANNOTATION_STATE ペイロードの num_namespaces インスタンスが続く。 これらの順番は重要であり、デシリアライズ処理中も保持しておくべきである。後続の INSTRUCTION_ANNOTATION ペイロードがインデックスを作成するからである。

ANNOTATION_STATE ペイロードは固定C構造体で始まる：

struct ANNOTATION_STATE_HEADER {
    uint32_t namespace_size;
    uint64_t state_size;
}

このヘッダーの直後には、 UTF-8 エンコードされたテキストが namespace_size バイト続き、これが名前空間を構成する。 これらのバイトの直後に、 state_size バイトの任意のデータが続く。 この「状態」ペイロードのフォーマットはQPYでは定義されていない。 代わりに、保存されたネームスペースに関連付けられた外部オブジェクトの責任となる。 アノテーションは完全にカスタムなので、ユーザーはシリアライズとデシリアライズのメソッドを提供しなければならない。

INSTRUCTIONの変更

INSTRUCTION 構造体は、 バージョン9の以前の定義と ABI互換の方法で変更されている。 新しい構造体はC構造体である（フィールド間や構造体の末尾にパディングがないことを思い出してほしい）：

struct INSTRUCTION {
    uint16_t name_size;
    uint16_t label_size;
    uint16_t num_parameters;
    uint32_t num_qargs;
    uint32_t num_cargs;
    uint8_t extras_key;
    uint16_t conditional_reg_name_size;
    int64_t conditional_value;
    uint32_t num_ctrl_qubits;
    uint32_t ctrl_state;
}

ここで、フィールド uint8_t extras_key は以前の uint8_t conditional_key を置き換える。 この違いは純粋に解釈の違いだ。 バイトの下位2ビットは、条件とそのタイプを定義するものとして解釈される。 バイトの上位ビットはフラグになり、 INSTRUCTION 構造体の末尾データに INSTRUCTION_ANNOTATIONS_HEADER フィールドが存在するかどうか（ビットがセットされている場合）を示す。

完全な命令ペイロードは、末尾のオブジェクトを含み、エレメント間のパディングバイトなしで、次のようにデータストリームに表示される：

struct INSTRUCTION;
uint8_t name[name_size];
uint8_t label[label_size];
uint8_t register[conditional_reg_name_size]; (1)
struct INSTRUCTION_PARAM;                    (2)
struct INSTRUCTION_ARG[num_qargs];
struct INSTRUCTION_ARG[num_cargs];
struct INSTRUCTION_PARAM[num_parameters];
INSTRUCTION_ANNOTATIONS;                     (3)

以下の注意事項が適用される：

1. extras_key の2つの下位ビットが値 2 を持つ場合、その条件が EXPRESSION であることを示し、 conditional_reg_name_size は常にゼロであることを示す。
2. このフィールドが存在するのは、 extras_key の下位2ビットが値 2 を持つ場合のみであり、その条件は EXPRESSION であることを示す。
3. このフィールドが存在するのは、 extras_key の上位ビットが設定されている場合のみである。 New INSTRUCTION_ANNOTATIONS を参照のこと。

新しい注釈

INSTRUCTION_ANNOTATIONS ペイロードはC構造体で始まる：

struct INSTRUCTION_ANNOTATIONS_HEADER {
    uint32_t num_annotations;
}

num_annotations このペイロードの直後には、 INSTRUCTION_ANNOTATION ペイロードのインスタンス（サイズは可変）が続く。

INSRTUCTION_ANNOTATION ペイロードは、以下のC構造体に、 payload_size に等しいバイト数（ ANNOTATION_PAYLOAD ）を加えたものである。

struct INSTRUCTION_ANNOTATION {
    uint32_t namespace_index;
    uint32_t payload_size;
}

namespace_index は、 ANNOTATION_HEADER で定義されている ANNOTATION_NAMESPACE オブジェクトのリストへの整数インデックスである。 注釈のシ リ ア ラ イ ゼーシ ョ ン名前空間は、 該当す る ペ イ ロ ー ド 内の UTF-8 エン コ ーデ ィ ン グ さ れた文字列です。

ANNOTATION_PAYLOAD オブジェクトの形式は QPY によって指定されていません。 ANNOTATION_HEADER 内の namespace_index で参照される名前空間とそれに関連するシリアライザーの状態に関連付けられた外部シリアライゼーションオブジェクトによって定義される。

PARAM_EXPR_ELEM_V13 内の変更

構造体自体は変更されていません。 op_code = 15ただし、コール（が、したがって lhs_type = 'p' および rhs_type = 'n'）を ParameterExpression.subs()PARAM_EXPR_ELEM_V13 表す の場合、末尾の MAPPING は、UUID の Parameter 生バイト列のキーを、置換された値にマッピングするようになりました。 以前（QPY バージョン 13 および 14 では）、このマッピングではパラメータ名をキーとして格納していました。

バージョン14

バージョン14では、新しいコアDURATIONタイプが追加された。 Type クラス Float および Durationおよび新しい式ノード・タイプ Stretch.

所要時間

Duration は、タイプの種類をエンコードする1バイトのASCII char でエンコードされ、その後にタイプによって異なるペイロードが続く。 定義されたコードは以下の通り：

EXPR_VAR_DECLARATION の変更

EXPR_VAR_DECLARATION 。 Var スタンドアロン変数と Stretch 識別子を表すのに使われるようになった。 この変更をサポートするために、使用タイプコードには、既存の項目に加えて、新たに2つの項目が追加された：

EXPRESSIONの変更点

EXPRESSIONタイプコードには、 s という新しい項目がある。 expr.Stretch ノードに対応する。

EXPR_TYPE の変更

次の表は、このバージョンで追加された新しい型クラスである：

EXPR_VALUE の変更

古典式の型システムは、intとboolの既存のエンコーディングに加えて、値リテラルの新しいエンコーディング型をサポートするようになった。 新しい値型エンコーディングは以下の通り：

バージョン13

ParameterExpressionバージョン 13 では、. 用のネイティブ Qiskit シリアライズ表現が追加されました。 以前のQPYのバージョンでは、基礎となる記号式をシリアル化するために、あるいは symengine のいずれ sympy かに依存していました。 ParameterExpressionバージョン 13 以降、QPY では、. を作成するために使用される API 呼び出しのシーケンスが表現されるようになりました。

シリアライズ形式における主な変更点は、 PARAMETER_EXPR ペイロードにあります。 ヘッダーに続くバイトには expr_size 、現在、struct の PARAM_EXPR_ELEM_V13 配列が格納されています。 ParameterExpressionこの配列は、1つの構造体ずつ読み込まれることを想定しており、各構造体は、を再構築するために実行すべき呼び出しの1つを表しています。

PARAM_EXPR_ELEM_V13

構造体の形式は次のように定義されている：

struct {
    unsigned char op_code;
    char lhs_type;
    char lhs[16];
    char rhs_type;
    char rhs[16];
} PARAM_EXPR_ELEM_V13;

ParameterExpressionこの op_code フィールドは、に追加される操作を定義するために使用されます。 以下の値を使用できます。

NULL の値255は、実際の操作ではなく、再帰的な定義を示すエントリーのオペコードフィールドを埋めるためにのみ使用される。 そして、 lhs_type と rhs_type フィールドは、オペランド・タイプを記述するために使用され、以下の UTF-8 エンコード文字のいずれかを指定することができる：

i型値が f、 c、 または の場合、対応する lhs または rhs のフィールド幅はそれぞれ128ビットとなる。 浮動小数点数の場合、リテラル値は0でパディングされたdoubleとしてエンコードされますが、複素数は実部と虚部の順でエンコードされ、それぞれ64ビットを消費します。 iの場合、その値は64ビットの符号付き整数としてエンコードされ、128ビットの全幅を埋めるために0でパディングされます。 n は None を表すために使用され、通常は使用されない引数を示すため、直接使用されることはありません。 このデータは p 、のUUIDであり、これは Parameter outer PARAMETER_EXPR ペイロードで map_elements 説明されているシンボルマップで参照することができます。 ParameterExpression型値が s の場合、これはネストされた に対する新しい再帰セクションの開始点を示します。 final_exprたとえば、次のスニペットでは、の中に内包されたがあり、これが expr ネストされた式を構成しています：

from qiskit.circuit import Parameter

x = Parameter("x")
y = Parameter("y")
z = Parameter("z")

expr = (x + y) / 2
final_expr = z**2 + expr

が検出された場合 s 、これは、および e が型指定 e` struct is reached, the next structs are used for a recursive definition. For both ``s されるまでは、データ値は使用されず、常に0に設定されることを示しています。 の u 型値は、置換呼び出しを表すために使用されます。 n``rhs_type これは に lhs_type のみ使用され、常に の と組み合わせて使用されます。 このデータ値は、その subs() 呼び出しにおける名前とその値の Parameter 対応関係をMAPPING形式でエンコードしたものの、バイト単位のサイズです。 マッピングデータは構造体の直後にあり、次の構造体はマッピングデータの直後に始まります。

バージョン12

バージョン12では、以下のサポートが追加された：

• メモリを持つ変数を含む回路 expr.Var 変数を含む。

ヘッダーの変更

個々の回路のHEADER構造体には、回路内の入力変数、キャプチャ変数、ローカル宣言変数の3つの uint32_t カウントが追加されている。 新しいフォームはこうだ：

struct {
    uint16_t name_size;
    char global_phase_type;
    uint16_t global_phase_size;
    uint32_t num_qubits;
    uint32_t num_clbits;
    uint64_t metadata_size;
    uint32_t num_registers;
    uint64_t num_instructions;
    uint32_t num_vars;
} HEADER_V12;

HEADER_V12 構造体の直後には、 V2 バージョンのヘッダーと同じ名前、グローバルフェーズ、メタデータ、レジスタ情報が続く。 レジスタの直後には、この回路の変数を定義する EXPR_VAR_STANDALONE のインスタンス num_vars がある。 その後は、QPYの以前のバージョンと同じように、カスタム定義と指示でデータが継続される。

EXPR_VAR_DECLARATION

EXPR_VAR_DECLARATION 。 expr.Var インスタンスを定義します。 Clbit または ClassicalRegister. ペイロードはCの構造体である：

struct {
    char uuid_bytes[16];
    char usage;
    uint16_t name_size;
}

その直後に EXPR_TYPE ペイロードが続き、 name_size バイトの UTF-8 エンコード文字列データが変数名を含む。

char 利用タイプコードは以下の値をとる：

EXPR_VAR の変更

EXPR_VAR 変数には、既存のものに加えて、新しいタイプコードとペイロードが追加された：

特筆すべきは、この新しい型コードは、使用される場所ごとに変数を再定義するのではなく、回路ヘッダーからあらかじめ定義された変数にインデックスを付けることである。

EXPRESSIONの変更点

EXPRESSIONタイプコードには、 i という新しい項目がある。 expr.Index ノードに対応する。

バージョン11

バージョン11は、以下の点を除き、バージョン10と同一です。 UUID.hexまず、CUSTOM_INSTRUCTION ブロック内の名前には、という形式 "_{uuid_hex}" の接尾辞が付いています。ここで uuid_hex 、は、によって返されるような UUID の 16 進数文字列です。 例: "b3ecab5b4d6a4eb6bc2b2dbf18d83e1e"。 第二に、オブジェクトの AnnotatedOperation サポートが追加されました。 Modifier注釈付き演算の基本演算は INSTRUCTION ブロックを使用して格納され、そのパラメータが 型であることを示すために追加 type の値 'a'``is added to indicate that the custom instruction is an annotated operation. The list of modifiers are stored as instruction parameters using INSTRUCTION_PARAM, with an additional value ``'m' が加えられます。 各修飾子は、MODIFIER 構造体を使用して格納されます。

MODIFIER

これは Modifier

struct {
    char type;
    uint32_t num_ctrl_qubits;
    uint32_t ctrl_state;
    double power;
}

AnnotatedOperationこれだけで、型 のオブジェクトをシリアル化するために必要なさまざまな種類の修飾子を格納するのに十分です。 このフィールド type は、 'c'``'i' 、 'p'、または のいずれかであり、それぞれ、修飾子が逆修飾子、制御修飾子、またはパワー修飾子のいずれであるかを表します。 2番目のケースでは、フィールド num_ctrl_qubits および ctrl_state が基本演算の制御ロジックを指定し、3番目のケースでは、フィールド power が基本演算の累乗を表します。

バージョン 10

バージョン10では、以下のサポートが追加された：

• Pulse スケジュールブロック内のシンボリック式だけでなく、型 ParameterExpression のオブジェクトに対する symengine-native シリアライゼーション。
• Qiskitの 0.45.0 リリースで追加されたクラスの TranspileLayout 新しいフィールド。

ファイルヘッダにsymbolic_encodingフィールドが追加され、新しいエンコーディング・タイプcharが導入された。各シンボリック・ライブラリに次のようにマッピングされる。 p はsympyエンコーディングを指し、 e はsymengineエンコーディングを指す。

FILE_HEADER の変更

V10、FILE_HEADERの内容はC structとして定義される：

struct {
    uint8_t qpy_version;
    uint8_t qiskit_major_version;
    uint8_t qiskit_minor_version;
    uint8_t qiskit_patch_version;
    uint64_t num_circuits;
    char symbolic_encoding;
} FILE_HEADER_V10;

レイアウトの変更

LAYOUT 構造体が更新され、 input_qubit_count フィールドが追加された。 バージョン10では、 LAYOUT ：

struct {
    char exists;
    int32_t initial_layout_size;
    int32_t input_mapping_size;
    int32_t final_layout_size;
    uint32_t extra_registers;
    int32_t input_qubit_count;
}

struct LAYOUT の後のレイアウトデータの残りの部分は、以前のバージョンと同様に表現されます。 Noneもし input qubit_count が < 0 である場合、それは オブジェクト TranspileLayout 内の と _output_qubit_list の両方が _input_qubit_count であることを示しています。

バージョン 9

バージョン9では、古典的な Expr ノードとそれに関連する Types.

expression

ノードは Expr ノードは可変幅データのストリームで表される。 ノードそのものは、（バイトストリームの順番に）次のように表される：

1. 1バイトのタイプコード識別器；
2. EXPR_TYPE オブジェクトである；
3. タイプコード固有の追加ペイロード；
4. 子EXPRESSIONペイロードのタイプコード固有の数(これらの数は、タイプコードによって暗示され、明示的に格納されない)。

それぞれの説明は以下の表の通り：

EXPR_TYPE

A Type は、タイプの種類をエンコードする1バイトのASCII char 、その後にタイプによって異なるペイロードが続く。 定義されたコードは以下の通り：

EXPR_VAR

これは Var ノードを表す。 これらはタイプコードと、その後にタイプコード固有のペイロードが続く：

EXPR_VALUE

これは、整数などの古典的な型システムにおけるリテラル・オブジェクトを表す。 現在、このようなリテラルはほとんどない。 これらはタイプコードとしてエンコードされ、その後にタイプコード固有のペイロードが続く。

INSTRUCTIONの変更

フィールド IfElseOp.condition、 SwitchCaseOp.targetWhileLoopOp.condition 、 における Expr ノードの使用をサポートするため、INSTRUCTION 構造体は、ABI 互換性を維持した形で、 以前の定義に変更されました。 新しい構造体は、C言語の構造体です：

struct {
    uint16_t name_size;
    uint16_t label_size;
    uint16_t num_parameters;
    uint32_t num_qargs;
    uint32_t num_cargs;
    uint8_t conditional_key;
    uint16_t conditional_reg_name_size;
    int64_t conditional_value;
    uint32_t num_ctrl_qubits;
    uint32_t ctrl_state;
}

唯一の変更は、 _Bool has_conditional に代わって uint8_t conditional_key のエントリーが追加されたことである。 この新しい conditional_key は、以下の数値を取り、これらの効果を持つ：

INSTRUCTION_PARAM の変更

EXPRESSION パラメータを定義する新しいタイプコード x が追加された。

バージョン 8

バージョン 8 では、属性 QuantumCircuit.layout に格納された の TranspileLayout 処理がサポートされました。 バージョン8では、回路ペイロードの末尾にあるキャリブレーションブロックの直後に、この LAYOUT 構造体が追加されました。 この構造体は、ある TranspileLayout クラスの3つの属性のサイズを示しています。

レイアウト

struct {
    char exists;
    int32_t initial_layout_size;
    int32_t input_mapping_size;
    int32_t final_layout_size;
    uint32_t extra_registers;
}

符号付き値のいずれかが -1 、これは対応する属性が None。

struct の LAYOUT 直後には、回路には存在しない独立したレジスタ定義（具体的にはバージョン4 で導入された形式）の extra_registers ための REGISTERS 構造体が配置されています。 さらに、属性を TranspileLayout.initial_layout 定義するための構造体 INITIAL_LAYOUT_BIT もあります initial_layout_size 。

初期レイアウトビット

struct {
    int32_t index;
    int32_t register_size;
}

ここで、 -1 の値は、 None （ビットにレジスタが関連付けられていない）を示す。 各 INITIAL_LAYOUT_BIT 構造体に続くのは、 utf8 エンコードされたレジスタ名の文字列のための register_size バイトである。

初期レイアウトに続いて、 input_mapping_size 、初期レイアウトからの物理ビットの位置を表す uint32_t 整数の配列がある。 これにより、配列のインデックスを入力マッピング位置とする仮想ビットのリストを構築することができる。

最後に、 final_layout_size uint32_t 整数の配列がある。 各要素は、回路の qubits 属性のインデックスであり、量子ビットの開始位置から回路の終了時の出力位置へのマッピングを構築することができる。

バージョン 7

バージョン7では、サブルーチンへの参照を維持したまま、 Reference 命令と ScheduleBlock プログラムのシリアライゼーションのサポートが追加されました：

from qiskit import pulse
from qiskit import qpy

with pulse.build() as schedule:
    pulse.reference("cr45p", "q0", "q1")
    pulse.reference("x", "q0")
    pulse.reference("cr45p", "q0", "q1")

with open('template_ecr.qpy', 'wb') as fd:
    qpy.dump(schedule, fd)

従来の SCHEDULE_BLOCK データ・モデルは維持されているが、バージョン7ではその直後に、参照されるサブルーチンのデータを表す MAPPING utf8 バイト・ブロックが追加されている。

Reference 、 SCHEDULE_BLOCK_INSTRUCTIONS グループに新しいタイプキー文字が追加された。

• y Reference

SCHEDULE_BLOCK_OPERANDS グループに、 Reference 命令のオペランド用の新しいタイプキー文字が追加された。これは、文字列のタプルであり、例えば、( “cr45p”, “q0”, “q1” )。

• oオペランド文字列

これは組み込みの Python 文字列と同じエンコーディングであることに注意してください。しかし、QPYの標準値エンコーディングは、文字列データに s 型の文字を使用します。これは、パルス命令オペランドのスコープ内の SymbolicPulse と競合します。 パルス命令のオペランドに表示される文字列データには、特殊文字（ o ）が予約されている。

さらに、バージョン7では、INSTRUCTION_PARM構造体に2つの新しい型キーが追加された。 "d" はデータなしで、スイッチ・ステートメント・サポート用のリテラル値を表す。 CASE_DEFAULT を表す。 "R" を表す。 ClassicalRegister または Clbitを表し、その後に INSTRUCTIONフィールドの条件の最初の要素で使われるレジスタや古典的なビットの説明と同じ書式が続く。

バージョン 6

バージョン6では、 ScalableSymbolicPulse。 これらのオブジェクトは、 SymbolicPulse オブジェクトのように保存され、読み込まれる。クラス選択が正しく処理されるように、クラス名がデータに追加される。

SymbolicPulse ブロックが SYMBOLIC_PULSE_V2 ヘッダーで始まるようになった：

struct {
    uint16_t class_name_size;
    uint16_t type_size;
    uint16_t envelope_size;
    uint16_t constraints_size;
    uint16_t valid_amp_conditions_size;
    _bool amp_limited;
}

バージョン5との唯一の変更点は、class_name_sizeが追加されたことである。 ヘッダーの直後には、 class_name_size utf8 バイトのクラス名が続く。 現在のところ、 SymbolicPulse または ScalableSymbolicPulse のいずれかがサポートされている。 残りのデータはバージョン5と同じである。

バージョン 5

バージョン 5 では、 バージョン 4 から、の ScheduleBlock サポートが追加され、INSTRUCTION メタデータペイロードと CUSTOM_INSTRUCTION ブロックの 2 つのペイロードが変更されました。 これらには、回路内のオブジェクトをより ControlledGate 適切に考慮できるよう、新しいフィールドが追加されました。 さらに、 MAPPING ブロックを実装するために、新しいペイロードMAP_ITEMが定義されています。

QPYバージョン5以上では、

struct {
    char type;
}

の直後に続くファイル・ヘッダー・ブロックは、ファイルに格納されているプログラム・タイプを表す。

• type==c の場合、 QuantumCircuit に従います
• type==s の場合、 ScheduleBlock ペイロードは次のようになる

スケジュールブロック

ScheduleBlock はQPY Version 5で初めてサポートされた。 これにより、ユーザーはパルス・プログラムをQPYバイナリ・フォーマットで以下のように保存できる：

from qiskit import pulse, qpy

with pulse.build() as schedule:
    pulse.play(pulse.Gaussian(160, 0.1, 40), pulse.DriveChannel(0))

with open('schedule.qpy', 'wb') as fd:
    qpy.dump(schedule, fd)

with open('schedule.qpy', 'rb') as fd:
    new_schedule = qpy.load(fd)[0]

回路とスケジュール・ブロックは、同じQPYインターフェースを通してシリアライズ、デシリアライズされることに注意。 入力データ型は暗黙のうちに分析され、スケジュールブロックを保存するための追加オプションは必要ありません。

スケジュールブロックヘッダー

ScheduleBlock ブロックは以下のヘッダーで始まる：

struct {
    uint16_t name_size;
    uint64_t metadata_size;
    uint16_t num_element;
}

これは、 name_size utf8 バイトのスケジュール名と、 metadata_size utf8 バイトのスケジュールに添付されたJSONシリアライズされたメタデータ辞書がすぐに続きます。

スケジュールブロック配置

次に、スケジュールブロックのアライメントコンテキストは、サポートされるコンテキストタイプを表す char で始まり、アライメントコンテキストに関連するパラメータを表す SEQUENCE ブロック AlignmentKind._context_params が続く。 コンテキスト・タイプcharは、各アライメント・サブクラスに以下のようにマッピングされる：

• l: AlignLeft
• r: AlignRight
• s: AlignSequential
• e: AlignEquispaced

コンテキスト・パラメーターにコールバック関数が格納されているため、 AlignFunc コンテキストはサポートされていないことに注意。

スケジュールブロック指示

このアライメント・ブロックには、さらに num_element 、ネストされたスケジュール・ブロックやスケジュール命令で構成されるブロック・エレメントが続く。 各スケジュール命令は、命令タイプを表す char で始まり、命令 operands を表す SEQUENCE ブロックが続く。 パルス Instruction のデータ構造は、インスタンスがクラスとオペランドのタプルによって一意に決定できるように統一されていることに注意。 char型の命令サブクラスへのマッピングは以下のように定義されている：

• a Acquire
• p Play
• d Delay
• f SetFrequency
• g ShiftFrequency
• q SetPhase
• r ShiftPhase
• b RelativeBarrier
• t TimeBlockade
• y: Reference 命令 (バージョン 0.7 の新機能)

スケジュールブロックオペランド

これらのインスタンスのオペランドは、標準的なQPY値のシリアライゼーション・メカニズムによってシリアライズすることができますが、スケジュールのオペランドにのみ現れる特別なオブジェクト・タイプがあります。 オペランドは SEQUENCEとしてシリアライズされるので、各要素はINSTRUCTION_PARAM pack structでパックされなければならない。各ペイロードは、char type と uint64_t size からなるヘッダーブロックで始まる。 特別なオブジェクトは以下のタイプキーで始まる：

• c: Channel
• w: Waveform
• s: SymbolicPulse
• o: string (オペランド文字列、バージョン 0.7 の新機能)

チャネル

チャネル・ブロックは、オブジェクト・データを Channel サブクラスにマッピングするチャネル・サブタイプ char で始まる。 マッピングは以下のように定義される：

• d: DriveChannel
• c: ControlChannel
• m: MeasureChannel
• a: AcquireChannel
• e: MemorySlot
• r: RegisterSlot

キーの直後には、INSTRUCTION_PARAMとして直列化されたチャンネル・インデックスが続く。

波形

波形ブロックはWAVEFORMヘッダーで始まる：

struct {
    double epsilon;
    uint32_t data_size;
    _bool amp_limited;
}

によって生成された複素数 ndarray バイナリ data_size バイトが続く。 numpy.save. これは、量子デバイスで再生される複雑なIQデータポイントを表している。 name は、INSTRUCTION_PARAM パック構造体のサンプルの後に保存され、文字列または None である。

SymbolicPulse

SymbolicPulse ブロックはSYMBOLIC_PULSEヘッダーで始まる：

struct {
    uint16_t type_size;
    uint16_t envelope_size;
    uint16_t constraints_size;
    uint16_t valid_amp_conditions_size;
    _bool amp_limited;
}

これに続くのは、 type_size utf8 バイトの SymbolicPulse.pulse_type 文字列で、"Gaussian" や “GaussianSquare” のような波形のクラスを表す。 そして、 envelope_size、 constraints_size、 valid_amp_conditions_size 、 utf8 バイトの直列化された記号式が、それぞれ SymbolicPulse.envelope、 SymbolicPulse.constraints、 SymbolicPulse.valid_amp_conditions、生成される。 これらの式の文字列表現は通常長いので、式のバイナリはpython zlib モジュールでデータ圧縮して生成される。

パルスのインスタンスを一意に指定するためには、関連するパラメータも格納する必要がある。パラメータは duration 、その他のパラメータは辞書として構成される。 辞書パラメータはまず MAPPING 形式でダンプされ、次に duration 、INSTRUCTION_PARAMパック構造体でダンプされる。 None最後に、 name は INSTRUCTION_PARAM パック構造体で保存される。

マッピング

MAPPINGは、任意のマッピング・オブジェクトの表現である。 これは、MAP_ITEMペイロードで表されるkey-valueペアの固定長 SEQUENCE である。

MAP_ITEMは、以下のように定義されたヘッダーで始まる：

struct {
    uint16_t key_size;
    char type;
    uint16_t size;
}

その直後には、 key_size utf8 バイトが辞書のキーを文字列で表し、 size utf8 バイトがQPY直列化可能な任意のオブジェクトデータ type である。

回路キャリブレーション

CIRCUIT_CALIBRATIONSブロックは、カスタム命令セットのパルス校正を定義するディクショナリである。 このブロックは以下のCALIBRATIONヘッダーで始まる：

struct {
    uint16_t num_cals;
}

その後に、 num_cals 長さの較正エントリーが続き、それぞれがCALIBRATION_DEFヘッダーで始まる：

struct {
    uint16_t name_size;
    uint16_t num_qubits;
    uint16_t num_params;
    char type;
}

校正定義ヘッダには、 name_size utf8 バイトのゲート名、 num_qubits 数列の量子ビットを表す整数の長さ、 num_params カスタム命令に関連するパラメータ用の INSTRUCTION_PARAM ペイロードの長さが続く。 type は、原則として、 ScheduleBlock または Schedule のいずれかであるパルスプログラムのクラスを示す。 QPY Version 5では、 ScheduleBlock ペイロードのみがサポートされている。 最後に、 SCHEDULE_BLOCK ペイロードが、各CALIBRATION_DEFエ ントリに対してパックされる。

指示

INSTRUCTIONブロックが変更され、属性 ControlledGate.num_ctrl_qubits および ControlledGate.ctrl_state をモデル化するために使用される 2 つの新しいフィールド num_ctrl_qubits および ctrl_state が追加されました。 新しいペイロードの構造体形式は次のとおりです：

struct {
    uint16_t name_size;
    uint16_t label_size;
    uint16_t num_parameters;
    uint32_t num_qargs;
    uint32_t num_cargs;
    _Bool has_conditional;
    uint16_t conditional_reg_name_size;
    int64_t conditional_value;
    uint32_t num_ctrl_qubits;
    uint32_t ctrl_state;
}

残りの命令ペイロードは同じである。 完全なペイロードの詳細については、 INSTRUCTIONSを参照してくださいすることができます。

カスタム_インストラクション

QPY バージョン 5 の CUSTOM_INSTRUCTION ブロックには、カスタム ControlledGate オブジェクトの 属性 ControlledGate.base_gate に格納されるオブジェクト qiskit.circuit.Instruction のサイズを定義するために使用される新しいフィールド base_gate_size が追加されています。 この変更により、CUSTOM_INSTRUCTION メタデータブロックは次のようになります：

struct {
    uint16_t name_size;
    char type;
    uint32_t num_qubits;
    uint32_t num_clbits;
    _Bool custom_definition;
    uint64_t size;
    uint32_t num_ctrl_qubits;
    uint32_t ctrl_state;
    uint64_t base_gate_size
}

CUSTOM_INSTRUCTION 構造体の直後には、 utf8 エンコードされた名前（サイズ name_size ）がある。

もし custom_definition が True である場合、その直後に続く size バイトには、そのゲートのカスタム定義に使用できる QPY 回路データが含まれていることを意味します。 もし custom_definition が False であるならば、その命令は不透明（すなわち定義なし）と見なすことができる。 この type フィールドは、カスタム定義によってどのようなタイプのオブジェクトが作成されるかを決定します。 InstructionGate もし なら 'g' 、それは オブジェクトになり、 'i' なら、それは オブジェクトになります。

これに続く base_gate_size バイトには、 ControlledGate.base_gate の INSTRUCTION ペイロードが含まれる。

ControlledGateさらに、 に対する type 付加値が追加 'c' され、これはカスタム命令がカスタム であることを示すために使用されます。

バージョン 4

バージョン4は、INSTRUCTION_PARAM構造体に2つの新しい型文字列、 None （データなしとしてエンコードされる）を表す z 、 q （QPY回路としてエンコードされる）を表す、 （RANGEとしてエンコードされる）を表す を追加した以外は、 バージョン 3と同じである。 QuantumCircuit (これはQPY回路としてエンコードされる）、 r は整数の range （これは RANGEとしてエンコードされる）、 t は sequence （これは SEQUENCEによって定義されるようにエンコードされる）を表す。 さらに、バージョン4では、レジスタ・インデックス・マッピング配列のタイプが uint32_t から int64_t に変更された。 もし配列要素のどれかの値が負であれば、それは回路に存在しないレジスタビットを表している。

REGISTERS ヘッダーのフォーマットも次のように更新された

struct {
    char type;
    _Bool standalone;
    uint32_t size;
    uint16_t name_size;
    _bool in_circuit;
}

これは、レジスタが回路の一部であるかどうかを表す in_circuit フィールドを追加するだけである。

RANGE

RANGE は、 range オブジェクトの表現である。 と定義されている：

struct {
    int64_t start;
    int64_t stop;
    int64_t step;
}

SEQUENCE

SEQUENCEは、任意のシーケンスオブジェクトの表現である。 シーケンスは任意のPythonオブジェクトの固定長のコンテナに過ぎないので、そのQPYはシーケンスを完全に表現することはできませんが、シーケンスの中身がINSTRUCTION_PARAMペイロードの他のQPYシリアライズ可能な型である限り、sequenceオブジェクトをシリアライズすることができます。

シーケンス命令のパラメータは、以下のように定義されたヘッダで始まる：

struct {
    uint64_t size;
}

その後に INSTRUCTION_PARAM ペイロードである size エレメントが続く。 シーケンスオブジェクトは、適切な型、例えば tuple にタイプキャストされる、 その後

バージョン 3

QPYフォーマットのバージョン3は、 バージョン2 と同一ですが、QPY内でネイティブに表現 PauliEvolutionGate するための構造体フォーマットが定義されている点が異なります。 PauliEvolutionGateこれを実現するため、CUSTOM_DEFINITIONS 構造体は、. を表す新しい型 value 'p' をサポートするようになりました。 カスタム指示テーブルのエントリには、文字 "###PauliEvolutionGate_" 列「」で始まり、その後にuuid文字列が続く一意の名前が生成されます。 このゲート名はQPYで予約されており、定義セットを持つカスタム Instruction オブジェクトにこの名前プレフィックスが含まれていると、エラーが発生します。 型 'p' が の場合、データペイロードは次のように定義されます：

PAULI_EVOLUTION

これは大まかな概要を示しています PauliEvolutionGate

struct {
    uint64_t operator_count;
    _Bool standalone_op;
    char time_type;
    uint64_t time_size;
    uint64_t synthesis_size;
}

その直後に operator_count 、 SPARSE_PAULI_OP_LIST_ELEM ペイロードによって定義された要素が続きます。 その後に、属性を time 表すバイトが続きます time_size 。 もし standalone_op が True であるならば、演算子は1つしか存在してはならない。 time_typeこれらのバイトのエンコーディングは、の値によって決まります。 'e'``'f'の取り得る値は、 'p'``time_type 、、および です。 Parameterもし time_type が 'f' であれば、それはダブル型であり、 'p' は PARAMETER で表される オブジェクトを Parameter 定義し、 e は PARAMETER_EXPR で表される オブジェクト（ただし、 ではない）を ParameterExpression 定義する。 その後に続くのは synthesis_size 、ゲートで使用されるクラスを EvolutionSynthesis 表す、 utf8 でエンコードされたJSONペイロードです。

疎パウリ演算子リスト要素

SparsePauliOpこれは……の一例です。

struct {
    uint32_t pauli_op_size;
}

SparsePauliOpその直後に、 pauli_op_size .npy形式 [2] のデータであるバイトが続きます。これは、.

ParameterQPY フォーマットのバージョン 3 では、を ParameterVectorElement として表現するための構造体フォーマットも定義されており、これはからの独立したサブクラスとして扱われます。 これにより、新しいパラメータ型 char 'v' が追加され、char ParameterVectorElement を表すようになりました。これは、INSTRUCTION_PARAM の型として string 値がサポートされるようになったものです。 これらのパラメータのペイロードは、以下で PARAMETER_VECTOR_ELEMENT として定義されています。

パラメータベクトル要素

PARAMETER_VECTOR_ELEMENT は、INSTRUCTION_PARAM のデータを表すオブジェクト ParameterVectorElement です。 PARAMETER_VECTOR_ELEMENT の内容は、次のように定義されています：

struct {
    uint16_t vector_name_size;
    uint64_t vector_size;
    char uuid[16];
    uint64_t index;
}

その直後には、 vector_name_size utf8、パラメータのベクター名を表すバイトが続く。

パラメータ_式

さらに、QPY形式のバージョン v3 以降では、a Parameter と ParameterVectorElement b を区別するようになったため、a ParameterExpression のペイロードを更新して、これらの型を区別できるようにする必要があります。 以下は、バージョン1およびバージョン2 の形式とほぼ同一であるが、structに map_elements シンボル型フィールドを追加するように変更されたペイロード形式である。

PARAMETER_EXPR は、INSTRUCTION_PARAM のデータを表すオブジェクト ParameterExpression です。 PARAMETER_EXPR の内容は、次のように定義されます

struct {
    uint64_t map_elements;
    uint64_t expr_size;
}

ヘッダーの直後には、 expr_size バイトの utf8 データがあり、式文字列が含まれている。これは、パラメータ式に対する式のシンプリスレッ プである。 それに続くのが、 map_elements の要素を含むシンボルマップである

struct {
    char symbol_type;
    char type;
    uint64_t size;
}

このキーは symbol_type 、その要素のシンボル表現のペイロードタイプを決定します。 ParameterVectorElementもし なら p 、それは を表し、 Parameter もし なら v 、それは を表します。 map要素の構造体の直後にsymbol mapキーのペイロードが続きます。もし symbol_type が p である場合は、 その直後にPARAMETERオブジェクト（構造体および utf8 の名前バイトの両方）が続きます。また、もし symbol_type が v である場合は、 構造体の直後にPARAMETER_VECTOR_ELEMENT（構造体および utf8 の名前バイトの両方）が続きます。 その後に size 、シンボルのデータ用のバイトが続きます。 typeデータ形式は、の値によって決まります。 もし type が p である場合、それは を表し、size は Parameter 0 となり、値はキーと同じになります。 同様に、もし が type である v 場合、それは を表し、値はキーと同じになるため、size は ParameterVectorElement 0 になります。 が type である f 場合、それは倍精度浮動小数点を表します。 もし type が である c 場合、それは倍精度複素数を表しており、これは COMPLEX によって表現されます。 int64_t最後に、型が i の場合、それは である整数を表します。

バージョン2

QPYフォーマットのバージョン2は、HEADERセクションが若干異なる以外はバージョン1と同じです。 残りのペイロード・フォーマットの詳細については、 バージョン1のセクションを参照されたい。

ヘッダー

HEADERの内容はC構造体として定義される：

struct {
    uint16_t name_size;
    char global_phase_type;
    uint16_t global_phase_size;
    uint32_t num_qubits;
    uint32_t num_clbits;
    uint64_t metadata_size;
    uint32_t num_registers;
    uint64_t num_instructions;
}

その直後に、回路名を表す utf8 形式のデータが バイト name_size 分続きます。 その直 global_phase_size 後に、グローバル位相を表すバイトが続きます。 global_phase_typeそのデータの内容は、の値によって決まります。 doubleもし であれば 'f' 、データは浮動小数点型であり、そのサイズは である。 Parameterが 'p' PARAM 構造体（後述）によって表されるオブジェクトを Parameter 定義する一方で、 e は PARAM_EXPR 構造体（後述）によって表される（ではない）オブジェクトを ParameterExpression 定義します。

バージョン 1

ヘッダー

C構造体として定義されたHEADERの内容は以下の通りである：

struct {
    uint16_t name_size;
    double global_phase;
    uint32_t num_qubits;
    uint32_t num_clbits;
    uint64_t metadata_size;
    uint32_t num_registers;
    uint64_t num_instructions;
}

この直後に、回路名を表す utf8 データが name_size バイト続く。

メタデータ

METADATAフィールドは、 UTF8 エンコードされたJSON文字列である。 HEADER（QPYファイルの最初にある固定サイズ）と name 文字列を読み込んだ後、 metadata_size バイト数を読み取り、JSONを解析して回路のメタデータを取得する。

REGISTERS

REGISTERSの内容は、REGISTERオブジェクトの番号である。 もしnum_registersが> 0なら、METADATAを読んだ後、次のように定義されたREGISTER構造体をその数だけ読む：

struct {
    char type;
    _Bool standalone;
    uint32_t size;
    uint16_t name_size;
}

type は 'q' または 'c'。

REGISTER構造体の直後には、 utf8 でエンコードされたサイズ name_size のレジスタ名がある。 name utf8 バイトの後、 size サイズの int64_t 値の配列があり、レジスタのインデックスと回路の量子ビットインデックスのマップを含む。 例えば、配列要素 0’s の値は、 register[0]の回路の量子ビットリストにおける位置のインデックスである。

standalone booleanは、レジスタが回路に追加されたスタンドアロン・レジスタとして構成されているか、既存のビットから作成されたかを決定する。 レジスタは、例えばその一部としてのみ構成されるビットを持つ場合、スタンドアロンとみなされる：

qr = QuantumRegister(2)
qc = QuantumCircuit(qr)

レジスタ qr はスタンドアロン・レジスタとなる。 というようなものだ：

bits = [Qubit(), Qubit()]
qr2 = QuantumRegister(bits=bits)
qc = QuantumCircuit(qr2)

qr2 は standalone を False に設定している。

カスタム定義

このセクションでは、回路内の任意の命令に対するカスタム定義を指定する。

CUSTOM_DEFINITION_HEADERの内容は以下のように定義される：

struct {
    uint64_t size;
}

sizeが0より大きい場合は、回路にカスタム命令が含まれていることを意味する。 各カスタム命令は、次のように定義された CUSTOM_INSTRUCTION ブロックで定義される：

struct {
    uint16_t name_size;
    char type;
    uint32_t num_qubits;
    uint32_t num_clbits;
    _Bool custom_definition;
    uint64_t size;
}

CUSTOM_INSTRUCTION 構造体の直後には、 utf8 エンコードされた名前（サイズ name_size ）がある。

もし custom_definition が True である場合、その直後に続く size バイトには、そのゲートのカスタム定義に使用できる QPY 回路データが含まれていることを意味します。 もし custom_definition が False であるならば、その命令は不透明（すなわち定義なし）と見なすことができる。 この type フィールドは、カスタム定義によってどのようなタイプのオブジェクトが作成されるかを決定します。 InstructionGate もし なら 'g' 、それは オブジェクトになり、 'i' なら、それは オブジェクトになります。

手順

INSTRUCTIONSの内容は、INSTRUCTIONメタデータ・オブジェクトのリストです

struct {
    uint16_t name_size;
    uint16_t label_size;
    uint16_t num_parameters;
    uint32_t num_qargs;
    uint32_t num_cargs;
    _Bool has_conditional;
    uint16_t conditional_reg_name_size;
    int64_t conditional_value;
}

このメタデータ・オブジェクトの直後には、 name の utf8 バイトの name_size バイトが続く。 name がQiskitで定義されている場合のInstructionクラスのQiskitクラス名です。 そうでない場合は、カスタム命令名に戻る。 name バイトに続いて、 label_size バイトがあり、ラベルが命令で設定されている場合は、 utf8 データがある。 ラベル・バイトに続いて、もし has_conditional が True ならば、 conditional_reg_name_size バイトのコンディショナル・レジスタ名のための utf8 データがある。 シングル・クラシカル・ビット条件の場合、レジスタ名 utf8 データの前にヌル文字 “x00” が付き、その後に、条件がオンになっている回路のクラシカル・ビット・インデックスを表す utf8 文字列整数が付く。

INSTRUCTION_ARG 構造体は、その命令の引数のリストを表す。 これらは、すべての量子引数（これらのnum_qargsがある）の後に、すべての古典引数（これらのnum_cargsがある）という順番になっている。

各INSTRUCTION_ARGの内容は以下の通り：

struct {
    char type;
    uint32_t index;
}

type は 'q' または 'c'。

命令のすべての引数の後に、 num_parameters INSTRUCTION_PARAM構造体でパラメータが指定されます。

各INSTRUCTION_PARAMの内容は以下の通りである：

struct {
    char type;
    uint64_t size;
}

各 INSTRUCTION_PARAM の後、続く size バイトはパラメータのデータです。 's'``'e'``'p'``'f'``'i'この type フィールドには、、、、、、 'c' 、または 'n' が入り、これによって形式が決まります。 整数の場合は 'i' 、 'f' double型の場合は、 's' 文字列（ utf8 としてエンコードされたもの）の場合は、 'c' 複素数であり、データはPARAMETER_EXPR セクションの構造体形式で表現されます。 Parameter'p' は、 PARAMETER 構造体によって表されるオブジェクトを Parameter 定義し、 e は（ではない）オブジェクトを ParameterExpression 定義し、 これはPARAMETER_EXPR 構造体によって表される （QPY フォーマットバージョン 3 では、フォーマットが若干変更されています。参照： PARAMETER_EXPR ）、 'n' numpy のオブジェクト（または numpy 型）を ndarray 表し、データが.npy 形式 [2] であることを意味します。また、QPY バージョン 3 'v' では、 PARAMETER_VECTOR_ELEMENT 構造体によって表される を表します。 ParameterVectorElement

パラメーター

パラメータは、INSTRUCTION_PARAM のデータを表すオブジェクトです Parameter 。 PARAMETER の内容は、次のように定義されています

struct {
    uint16_t name_size;
    char uuid[16];
}

その直後に、 name_size utf8、パラメータ名を表すバイトが続く。

パラメータ_式

PARAMETER_EXPR は、INSTRUCTION_PARAM のデータを表すオブジェクト ParameterExpression です。 PARAMETER_EXPR の内容は、次のように定義されます

PARAMETER_EXPRデータはヘッダーで始まる：

struct {
    uint64_t map_elements;
    uint64_t expr_size;
}

ヘッダーの直後には、 expr_size バイトの utf8 データがあり、式文字列が含まれている。これは、パラメータ式に対する式のシンプリスレッ プである。 それに続くのが、 map_elements の要素を含むシンボルマップである

struct {
    char type;
    uint64_t size;
}

その直後に PARAMETER 、シンボルマップのキーに対応するオブジェクト（構造体と utf8 名のバイトの両方）が続きます。 その後に size 、シンボルのデータ用のバイトが続きます。 typeデータ形式は、の値によって決まります。 もし type が p である場合、それは を表し、size は Parameter 0 となり、値はキーと同じになります。 が type である f 場合、それは倍精度浮動小数点を表します。 もし type が c である場合、それは倍精度複素数を表しており、これは COMPLEX で表現される。 int64_t最後に、型が i の場合、それは である整数を表します。

複雑

QPYで倍精度複素数値を表現する場合、以下の構造体が使用される：

struct {
    double real;
    double imag;
}

これは、 Python 'の複合型の内部C表現と一致する。 [3]

参照

[1 ]

https://tools.ietf.org/html/rfc1700

[2] (1,2 )

https://numpy.org/doc/stable/reference/generated/numpy.lib.format.html

[3]

https://docs.python.org/3/c-api/complex.html# c.Py_complex