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自体のフォーマットは変更されませんが、パッキングされた進化ゲートに直後に続く演算子のフォーマットが更新されます。 SPARSE_PAULI_OP_LIST_ELEM形式で定義されたoperator_count要素の代わりに、ペイロードは各演算子の型を指定し、型 SparsePauliOp または の演算子を区別するようになりました SparseObservable。

PAULI_EVOLUTION に続く新しいペイロードには、ブール値 ("!?") に続いて演算子が続くシーケンスが、正確に operator_count 個含まれる。 ブール値がの場合 True、演算子はであり SparseObservable 、新しいSPARSE_OBSERVABLE形式（下記参照）で解釈される。 もしそうであれば False、演算子は SparsePauliOp であり、既存のSPARSE_PAULI_OP_LIST_ELEM形式に従って解釈される。

新しい SPARSE_OBSERVABLE

SPARSE_OBSERVABLE形式は、によって SparseObservable与えられるのインスタンスを表す

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 内の変更

構造体自体に変更はない。 しかし、呼を表す PARAM_EXPR_ELEM_V13 （、したがって、 ）の場合、末尾のMAPPINGは、呼の生バイトのキーをマップ する。 ParameterExpression.subs()op_code = 15 したがって、 lhs_type = 'p' と rhs_type = 'n' ）では、末尾の MAPPINGは、UUIDの生バイトのキーを置換された値に マップする。 Parameter UUIDの生のバイトのキーを置換された値にマップする。 以前は (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

バージョン13では、Qiskitのネイティブなシリアライズ表現として ParameterExpression. 以前のQPYバージョンは、基礎となる記号式を直列化するために sympy または symengine に依存していました。 バージョン 13 以降、QPY は、.NET の作成に使用される一連の API 呼び出しを表します。 ParameterExpression.

シリアライズ形式の主な変更点は、 PARAMETER_EXPR ペイロードである。 先頭に続く expr_size バイトには、 PARAM_EXPR_ELEM_V13 構造体の配列が含まれるようになった。 この配列は、構造体を1つずつ読み込むことを意図している。 ParameterExpression.

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;

op_code 。 ParameterExpression. 以下の値を使用できます。

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

タイプ値が f、 c、 i の場合、対応する lhs 、 rhs のフィールド幅はそれぞれ128ビットである。 浮動小数点数の場合、リテラル値は0パディング付きの2倍としてエンコードされ、複素数は実数部と虚数部の順でエンコードされ、それぞれ64ビットを占める。 i の場合、値は64ビットの符号付き整数としてエンコードされ、128ビット幅いっぱいに0パディングが施される。 n は、 None を表すために使用され、通常は使用されない引数を示すため、直接使用されることはない。 p のUUIDである。 Parameter これは、 map_elements の外側 PARAMETER_EXPR ペイロードに記述されているシンボルマップで検索できる。 型の値が s の場合、入れ子になった ParameterExpression. 例えば、次のスニペットでは、 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` struct is reached, the next structs are used for a recursive definition. For both ``s と e の型が現れるまで、データ値は使用されず、常に0に設定されることを示す。 型値 u は、置換コールを表すのに使われる。 これは lhs_type にのみ使用され、常に n の rhs_type と対になっている。 データ値は、 MAPPINGでエンコードされた、以下のような名前のマッピングのバイトサイズである。 Parameter のマッピングのバイトサイズである。 subs() を呼び出します。 マッピング・データは構造体の直後にあり、次の構造体はマッピング・データの直後に始まる。

バージョン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と同じである。 まず、CUSTOM_INSTRUCTIONブロックの名前は、 "_{uuid_hex}" という形のサフィックスを持ちます。 uuid_hex は、 UUID.hex が返すようなuuidの16進文字列です。 例: "b3ecab5b4d6a4eb6bc2b2dbf18d83e1e"。 第二に AnnotatedOperation オブジェクトをサポートする。 注釈付き操作の基本操作は、INSTRUCTIONブロックを使って格納され、パラメータが Modifier 型であることを示すために、 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 は、 'i'、 'c' 、 'p' のいずれかであり、修飾子がそれぞれ逆修飾子、制御修飾子、パワー修飾子のいずれであるかを表す。 2つ目の場合、フィールド num_ctrl_qubits と ctrl_state は基本操作の制御ロジックを指定し、3つ目の場合、フィールド power は基本操作のパワーを表す。

バージョン 10

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

• 型のオブジェクトのためのsymengineネイティブなシリアライゼーション。 ParameterExpression 型のオブジェクトとパルススケジュールブロックの記号式に対して symengine ネイティブなシリアライズを行います。
• の新しいフィールドです。 TranspileLayout0.45.0 クラスの新しいフィールドが追加されました。

ファイルヘッダに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;
}

LAYOUT 構造体以降の残りのレイアウト・データは、以前のバージョンと同様に表現される。 もし、 input qubit_count が ˶< 0 であれば、 _input_qubit_count と _output_qubit_list の両方が、 であることを示す。 TranspileLayout オブジェクトの None。

バージョン 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の変更

フィールドでの Expr フィールドでの IfElseOp.condition, WhileLoopOp.condition および SwitchCaseOp.target、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では TranspileLayout 属性に格納された QuantumCircuit.layout 属性に格納された バージョン8では、回路ペイロードの最後にあるキャリブレーション・ブロックの直後に、 LAYOUT 構造体があります。 この構造体は、クラスの3つの属性のサイズの概要を示す。 TranspileLayout クラスの

レイアウト

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

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

LAYOUT 構造体の直後に、 extra_registers （特にバージョン4で導入されたフォーマット）回路に存在しないスタンドアロン・レジスタ定義用の REGISTERS 構造体がある。 次に、 initial_layout_size INITIAL_LAYOUT_BIT 構造体がある。 TranspileLayout.initial_layout 属性を定義する構造体があります。

初期レイアウトビット

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は、 ScheduleBlock のサポートを追加し、INSTRUCTIONメタデータペイロードとCUSTOM_INSTRUCTIONブロックの2つのペイロードを変更することにより、 バージョン4から変更された。 これらに新しいフィールドが追加され 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ブロックが修正され、2つの新しいフィールド num_ctrl_qubits と ctrl_state が追加された。 ControlledGate.num_ctrl_qubits と ControlledGate.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ブロックには、カスタム・オブジェクトの base_gate_size 属性に格納されたオブジェクトのサイズを定義するために使用される新しいフィールド が追加されました。 qiskit.circuit.InstructionControlledGate.base_gate 属性に格納されたオブジェクトのサイズを定義するために使用されます。 ControlledGate オブジェクトの 属性に格納されるオブジェクトのサイズを定義するために使用されます。 この変更により、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 フィールドは、カスタム定義で作成されるオブジェクトのタイプを決定します。 'g' 。 Gate オブジェクトになり、 'i' Instruction オブジェクトになる。

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

type さらに、カスタム命令がカスタムであることを示すために使用される 'c' 。 ControlledGate.

バージョン 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 表現するための構造体フォーマットを定義している点が異なります。 これを実現するため、CUSTOM_DEFINITIONS 構造体は、. PauliEvolutionGateを表す新しい 'p' 型 value をサポートするようになりました。 カスタム指示テーブルのエントリには、文字列で始まり、その後に "###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;
}

この直後に、 SPARSE_PAULI_OP_LIST_ELEM ペイロードで定義された operator_count 要素が続く。 続いて、 time 属性を表す time_size バイトがある。 もし standalone_op が True ならば、オペレーターは一人しかいないはずだ。 これらのバイトのエンコーディングは、 time_type の値によって決定される。 time_type の取り得る値は、 'f'、 'p'、 'e' である。 もし time_type は 'f' それはダブルです 'p' 定義する Parameter PARAMETER で表されるオブジェクト、 e 定義する ParameterExpression オブジェクト（ Parameter ) は PARAMETER_EXPR で表されます。 synthesis_size これは utf8 でエンコードされた json ペイロードである。 EvolutionSynthesis クラスのペイロードです。

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

これは SparsePauliOp.

struct {
    uint32_t pauli_op_size;
}

.npyフォーマットの [2] データである pauli_op_size バイトが続く。 SparsePauliOp.

QPYフォーマットのバージョン3では、構造体フォーマットも定義されています。 ParameterVectorElement とは異なるサブクラスとして Parameter. を表す新しいパラメータ・タイプ char 'v' が追加されました。 ParameterVectorElement これは、INSTRUCTION_PARAMの文字列型値としてサポートされます。 これらのパラメー タのペイロードは、 PARAMETER_VECTOR_ELEMENTとして以下に定義される。

パラメータベクトル要素

PARAMETER_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 では Parameter と ParameterVectorElement のペイロードは ParameterExpression を区別するように更新する必要がある。 以下は、バージョン1およびバージョン 2のフォーマットとほぼ同じであるが、シンボル・タイプ・フィールドを含むように 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 キーは、要素のシンボル表現のペイロードタイプを決定します。 が の場合、 p それは を表し、が の場合 Parameterv 、それは を表す ParameterVectorElement。 map要素の構造体の直後にsymbol map keyペイロードが続きます。もし symbol_type が p である場合は、 その直後にPARAMETERオブジェクト（構造体および utf8 名のバイトを含む）が続きます。また、もし symbol_type が v である場合は、 構造体の直後にPARAMETER_VECTOR_ELEMENT（構造体および utf8 名のバイトを含む）が続きます。 その後に、シンボルの size データ用のバイトが続きます。 データ形式は、の値によって異なります type。 もし type が p である場合、それは を表し、size は Parameter 0 となり、値はキーと同じになります。 同様に、もし が type である v 場合、それは ParameterVectorElement を表し、値はキーと同じになるため、size は 0 になります。 が type である場合 f 、それは倍精度浮動小数点数を表します。 が の場合 c``type 、それは倍精度複素数を表し、これは COMPLEX 型で表現されます。 最後に、型が の場合 i 、それは である整数を表します int64_t。

バージョン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 の値によって決まる。 もし 'f' なら、データはfloatで、 double のサイズである。 'p' 。 Parametere オブジェクトを定義している。 ParameterExpression オブジェクト（これは Parameterでない）オブジェクトを定義する。

バージョン 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 フィールドは、カスタム定義で作成されるオブジェクトのタイプを決定します。 'g' 。 Gate オブジェクトになり、 'i' Instruction オブジェクトになる。

手順

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 バイトがパラメータのデータである。 type フィールドには、 'i'、 'f'、 'p'、 'e'、 's'、 'c' 、 'n' のいずれかを指定する。 'i' は整数、 'f' はダブル、 's' は文字列（ utf8 としてエンコードされる）、 'c' は複合体であり、データは PARAMETER_EXPR セクションの struct フォーマットで表現される。 'p' 定義する Parameter PARAMETER 構造体で表されるオブジェクト e 定義する ParameterExpression オブジェクト（ Parameter ）は PARAMETER_EXPR 構造体で表現されます（QPYフォーマットバージョン3 ではフォーマットが若干調整されています。PARAMETER _EXPRを参照してください）。 'n' numpyのオブジェクトを表します（ ndarray またはnumpy型）はデータが.npy形式であることを意味します [2] データ、およびQPY バージョン3 'v' を表す ParameterVectorElement これは PARAMETER_VECTOR_ELEMENT 構造体によって表されます。

パラメーター

PARAMETERは 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 なら、それは Parameter を表し、サイズは0になる。 type が f の場合、倍精度浮動小数点を表す。 type が c の場合、倍精度複素数を表し、 COMPLEXで表される。 最後に、typeが i の場合は、 int64_t である整数を表す。

複雑

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