dataesr/scientific-paragraphs-categorization huggingface dataset:
We adopt the methodology presented in Section 4. 1 and adapt the key ingredients of deductive verification to the case of circuit-building quantum programs. Hence, Qbricks is equipped with: a domain specific language (DSL) for building circuit families, a dedicated logical specification language, a novel symbolic representation (HOPS) and a new Hoare-style logic -called Hybrid Quantum Hoare Logic (HQHL). Circuit representation. The language Qbricks-DSL is only aimed at implementing quantum algorithms and specifications provided in the form of Figure  2. The circuits used in quantum algorithms act in general on contiguous blocks of memory registers and consist of simple compositions and hierarchical descriptions. Thus, unlike existing quantum programming languages such as Quipper  [33]  or Qwire  [58] , for Qbricks there is no need for complex wire manipulation.
Following this analysis, the low-level circuit-representation we choose as a target Qbricks is akin to the one of qPCF  [56] : a circuit is a simple compositional structure consisting of base gates and circuit combinators such as sequential and parallel composition, control, inversion, etc. These constructions are packaged withing a domain-specific language (DSL) aimed at describing families of circuits. Symbolic representation of quantum circuits. As mentioned in Section 2. 5, if path-sums offer a compositional specification framework, they address the case of fixed-size circuits. In particular, one cannot give specification to general, parametrized programs describing families of circuits. Qbricks proposes a solution to this limitation, by unifying what can be done with the matrix and the path-sum semantics.
Our proposal is a higher-order path-sum semantics (HOPS). On one hand, we keep the functional view on the action of circuits on quantum registers, making it suitable for deductive verification. On the other hand, we extend its syntax to support parametric circuit construction, high-level circuit combinators and reference to Qbricks-DSL constructs. Specification and verification. It turns out that HOPS offer a very convenient specification mechanism for quantum programs. They form the bedrock of the Qbricks-DSL specification language -together with a few other theories such as bit-vectors, integers or complex values. It also turns out that HOPS are convenient for verification purpose too: we design a proofobligation generation procedure within HQHL dedicated to circuit-building quantum languages, yielding proof obligations in the Qbricks-DSL (first-order) logic.
Finally, while part of the Qbricks-DSL logic can be directly handled by automated solvers (such as SMT), we add dedicated equational theories and axioms for those parts of the logic (e. g. , HOPS manipulation or complex values). Implementation. We implement Qbricks as a domain-specific language embedded in the Why3 deductive verification tool  [11, 27] , allowing to take advantage of its advanced programming, specification and verification features for classical programs. We add all quantum-related features on top of it. An overview of Qbricks certified implementation process is depicted in Figure  8 : the user writes a Qbricks-DSL programs together with Qbricks-Spec specifications. Our HQHL engine produces proof obligations in Qbricks-DSL logic. Taking advantage of the interface provided by Why3 embedding, the user can either directly send these proof obligations to a series of SMT-solvers for validation, together with our circuits specifications equational theories, or facilitate solving by use of a series of interactive predicate transformation commands (such as introduction of lemmas or hypotheses, beta-reduction, etc).
5 Qbricks-DSL Qbricks is structured as a domain-specific language (DSL), called Qbricks-DSL, and a domainspecific logical specification language called Qbricks-Spec. The language is targeted for circuit description: measurement is out of the scope of the language, and all Qbricks-DSL expressions are terminating. We follow a very simple strategy for circuit building: we use a regular inductive datatype for circuits, where the data constructors are elementary gates, sequential and parallel composition, and ancilla creation. In particular, unlike e. g. Quipper or Qwire, a quantum circuit is not a function acting on qubits: it is a simple, static object. Nonetheless, for the sake of implementing Ph(n) H R z (n) CNOT PAR(M, N ) SEQ(M, N ) Fig. 9. Circuit combinators quantum circuits from the literature this does not restrict expressivity as they are usually precisely represented as sequences of blocks.
Even if the language does not feature measurement, it is nonetheless possible to reason on probabilistic outputs of circuits, if we were to measure the result of a circuit. Indeed, this can be expressed in a regular theory of real and complex numbers. Qbricks-DSL is designed as a first-order, functional language: for the purpose of circuit construction, this is enough and designing a deductive system for it can then be done in a canonical way, following e. g. Why3 strategy. Similarly, the specification language Qbricks-Spec is a first-order predicate language, equipped with various equational theories. This makes proof-obligations more easily amenable to automated solvers. In the rest of this section, we present the language Qbricks-DSL. Section 6 is then devoted to Qbricks-Spec while Section 7 to the deduction rules.
5. 1 Syntax of Qbricks-DSL. The DSL Qbricks-DSL is a small first-order functional, call-byvalue language with a special datatype circ as the media to build and manipulate circuits. The core of Qbricks-DSL can be presented as a simply-typed calculus, presented in Figure  10. The basic data constructors for circ are CNOT, SWAP, ID, H, Ph(e) and R z (e) (see Table  16  in the Appendix for their semantics). The constructor for high-level circuit operations are sequential composition SEQ, parallel composition PAR and ancilla creation/termination ANC (see Figure  9  for details). On top of circ, the type system of Qbricks-DSL features the type of integers int (with constructors n, one for each integer n), booleans bool (with constructors tt and ff), and n-ary products (with constructor ⟨e 1 ,. , e n ⟩).
The rules which we do not provide are the ones for the control operation ctl: the intuition behind their definition can be found in Figure  9. For the elementary gates, any definition can be used (see e. g. [54] ), as long as it can be written with the chosen set of gates. One just has to then adjust the lemmas referring to ctl in Qbricks-Spec. Similarly, the invert Language constructs Assuming that there is a declaration f (x 1 ,. , x n ) ≜ e. f (v 1 ,. , v n ) → e[x 1 := v 1 ,. , x n := v n ] let ⟨x 1 ,. , x n ⟩ = ⟨v 1 ,. , v n ⟩ in e → e[x 1 := v 1 ,. , x n := v n ] if tt then e 1 else e 2 → e 1 if ff then e 1 else e 2 → e 2 when n ≤ 0: iter f n a → a when n > 0: iter f n a → f (iter f n -1 a) Constant functions (subset of the rules) n + m → n + m n -m → n -m n * m → n * m size(ID) → 0 size(SWAP) → 0 size(д) → 1 (д other gate) size(SEQ(v 1 , v 2 )) → size(v 1 ) + size(v 2 ) size(PAR(v 1 , v 2 )) → size(v 1 ) + size(v 2 ) size(ANC(v)) → size(v) width(CNOT) → 2 width(SWAP) → 2 width(д) → 1 (д other gate) width(SEQ(v 1 , v 2 )) → width(v 1 ) width(PAR(v 1 , v 2 )) → width(v 1 ) + width(v 2 ) width(ANC(v)) → width(v) -1 invert(SEQ(v 1 , v 2 )) → SEQ(invert(v 2 ), invert(v 1 )) invert(PAR(v 1 , v 2 )) → PAR(invert(v 1 ), invert(v 2 )) invert(ANC(v)) → ANC(invert(v)) Table  12.
Operational semantics for Qbricks-DSL of elementary gates are not given: we can choose the usual ones from the litterature -and this definition is then parametrized by the choice of gates. 5. 3 Properties. Note that the target low-level representation for an expression of type circ is a value made of the circuit data constructors. This is derived from the safety properties of the language: Property 5. 3. 1 (Safety properties and normalization). Provided that Γ ⊢ e : A and e → e ′ , then Γ ⊢ e ′ : A. Provided that ⊢ e : A is a closed expression, and provided that all the function in e recursively admits (external) definitions, then either e is a value or it reduces. Finally, the reduction strategy (→) is normalizing: there does not exist an infinite reduction sequence e 1 → e 2 →. □ Example 5.
All these syntactic and semantic constraints are thus expressed in Qbricks-Spec, our domainspecific logical specification language, and meant to be sent as proof obligations to a proof engine. Example 5. 2. Note how the circuit generated by main in Example 5. 1 is not necessarily a valid circuit (although in this case it is). This is one of the constraints that can be handled by Qbricks-Spec, as shown in Example 6. 2.
Denotational semantics. As all expressions in Qbricks-DSL are terminating, one can use regular sets as denotational semantics for the language. In order to be able to handle the partial definitions coming up in Section 6, we include in the denotation of each type an "error" element ⊥ We therefore define the denotation of basic types as the set of their values: [|bool| ] = {tt, ff, ⊥}, [|int| ] = Z ∪ {⊥} and [|circ| ] = {v | ⊢ v : circ} ∪ {⊥}. Product types are defined as the set-product: [|A 1 × • • • × A n | ] = ([|A 1 | ] × • • • × [|A n | ]) ∪ {⊥} and [|⊤| ] = {⋆, ⊥}, the singleton set. Finally, functions are defined as set-functions from the input set to the output set. The denotation of the language constructs are the usual one in a semantics based on sets ; for the constant functions, the definitions are the canonical ones: arithmetic operations maps to arithmetic operations for instance.
4. 6. 1 Syntax of Qbricks-Spec. Qbricks-Spec consists of a set of dedicated relations and functions, together with a language of algebraic expressions on top of a first-order logic, together with logical libraries to express constraints. We define Qbricks-Spec as a first-order, predicate logic with the following syntax. Formula ϕ,ψ : := ϕ ∨ ψ | ϕ ∧ ψ | ¬ϕ | ϕ → ψ | R( ê1 ,. , ên ) First-order expression ê ::= x | c( ê1 ,. , ên ) | f ( ê1 ,. , ên ) | f ℓ ( ê1 ,. , ên ). The first-order expressions ê form a subset of Qbricks-DSL: they are restricted to variables and (formal) function calls to other first-order expressions. Unlike regular, general expressions -meant to be computational vehicles-these first-order expressions only aim at being reasoned upon. The functions names are then expanded with logic functions f ℓ with no computational content.
In order to be able to express program specifications with pre-and post-conditions, we finally define a HQHL sequent of the form ∆ ⊩ {ϕ}e{ψ } : A (we omit the type A when irrelevant or clear). The formula ψ can make use of a reserved free variable result of type A. Such a sequent is then well-formed provided that ∆ ⊢ ϕ : bool, ∆, result : A ⊢ ψ : bool and ∆ ⊢ e : A are valid typing judgments. Note how the reserved free variable result is being added to ∆ for typing ψ. For convenience, we also extend the notation to result i to stand for the ith projection of result when A is of the form A 1 × • • • × A n. Then the point is that first, families of quantum circuits can be described in Qbricks-DSL and specifications in Qbricks-Spec, and second, that one can come up with a set of meaningful axioms that are enough to derive these specifications.
THE HQHL DEDUCTION SYSTEM Thanks to the logic judgments presented in Section 6. 5, it is possible to reason with Qbricks-Spec formulas on expressions written in Qbricks-DSL. If we showed how to give a semantical meaning to the validity of a judgment, we have not explained how to derive such a validity from first principles. This is the purpose of the current section. Property 7. 0. 1 (Validity of the deduction rules). All of the deduction rules that we add in this section are sound with respect to the semantics. □ Note that we do not aim in this section at being exhaustive: we only aim at giving an intuition as of how and why one can rely on an automated deductive system to derive Qbricks-Spec judgments. In particular, we show how to break down a program specification into a set of proof obligations that can be sent to an SMT solver to be automatically discharged.
IMPLEMENTATION The Qbricks framework described so far is implemented as a DSL embedded inside the Why3 deductive verification platform  [11, 28] , written in the WhyML programming language. 4 This allows us to benefit from several strengths of Why3, such as efficient code extraction toward Ocaml, generation of proof obligations (to implement the HQHL mechanism) and access to several proof means. Indeed, a dedicated interface enables direct access to proof obligations and either send them to a set of automatic SMT-solvers (CBC4, Alt-Ergo, Z3, etc. ), or enter a number of interactive proof transformation commands (calls for lemmas or hypotheses, term substitutions, etc. ) or even send them towards proof assistants (Coq, Isabelle/HOL) -we do not use this option in our case-studies. The development itself counts 17,000+ lines of code, including 400+ definitions and 1700+ lemmas, all proved within Why3.
Regular path-sums. Amy  [1, 2]  uses path sums for the verification of several circuits of complexity similar to that of QFT (QFT, Hidden shift, Toffoli generalized, etc). Yet, these experiments consider fixed circuits (up to 100 qubits) and the technique cannot be applied to parametric families of circuits or circuit-building languages. QHL. Liu et al. [50]  report about the parametric verification of Grover search algorithm, on a restricted case 8  and in the high-level algorithm description formalism of QHL -especially QHL has no notion of circuit. Interestingly, the generic verification of our low-level implementation is 5× smaller than theirs: 3184 total lines vs 583 total lines (416 lines + 167 commands). Qwire. Finally, Hietala et al. [37]  have presented in their 2019 preprint a fully verified parametric (circuit-building) implementation of the Deutsch-Josza algorithm in Coq.
This implementation is given two independent correction proofs. As already pointed out, DJ is more a standard teaching example (with no practical application) than a representative quantum algorithm -roughly speaking, 10× smaller than Grover and 20× smaller than (full) Shor-OF. Moreover, our development requires significantly less efforts than theirs: less code (53 vs 74 lines) and 5. 5× less proof commands (39 vs 222) for their textbook-style version -the one closest to our own version  9. 9. 4 Summary. It appears that Qbricks provides a powerful framework for the development of formally verified parametric implementations of realistic quantum algorithms, setting up a new baseline in terms of quantum program formal proofs and achieving high scores in terms of proof automation.
This framework leads to a graphical proof assistant  [44]  geared at certifying the semantic equivalence between circuit diagrams, with application to circuit equivalence checking and certified circuit compilation and optimization  [21, 22, 43 ]. Yet, ZX-calculus is restricted to fixed circuits and cannot handle parametrized families of circuits or circuit-building languages. Other quantum applications of formal methods. Huang et al. [40, 41]  proposes a "runtimemonitoring like" verification method for quantum circuits, with an annotation language restricted to structural properties of interest (e. g. , superposition or entanglement). Verification of these assertions is led by statistical testing instead of formal proofs. The recent Silq language  [10]  also represents an advance in the way toward automation in quantum programming.
CONCLUSION We have presented Qbricks, the first formal verification environment for circuit-building quantum programs -featuring clear separation between code and proof, parametric specifications and proofs, high degree of proof automation and allowing to encode quantum programs in a natural way. We build on best practices of formal verification for the classical case and tailor them to the quantum case. Especially, while relying on the general framework of deductive verification, we design a new domain-specific circuit-building language Qbricks-DSL for quantum programs together with a new logical specification language Qbricks-Spec and the novel Hybrid Quantum Hoare Logic. Finally, we introduce and intensively build upon higher-order path sums (HOPS), a symbolic representation convenient for both specification (parametricity) and automation (closure).
E IMPLEMENTATION: MORE DETAILS We provide here more details about the implementation, complementing Section 8. E. 1 Framework overview. The overall Qbricks verification chain is depicted in Figure  22. Implementation. The first step concerns the design of an algorithm A with parameters -→ p thanks to Qbricks-DSL and Qbricks-Spec. Qbricks is embedded in the Why3 programming language (called WhyML). We provide for it a set of mathematical libraries, enabling reasoning about Qbricks-Spec formulas (see Section E. 2 below for further details about these). Note that specifications are inserted within the implementation, as decorations for functions. The specification material may also contain, still within the implementation, intermediary lemmas and ghost material (either ghost definition for functions objects that are used exclusively for the specifications, or ghost elements inserted as parameters for non-ghost functions).
Code extraction, PO generation. Next, we can perform two different Why3 compilation operations: • Code extraction, which basically consists in deleting all the ghost material from the implementation. It results in a simple Ocaml implementation of A with parameters -→ p. • Compilation of the specification code, generating: first order logic proof obligations (POs). first order logic axioms, formalizing definitions from the algorithm implementation. They contribute to the logical context to evaluate PO satisfaction, together with, for any function f , specifications for functions above f or from imported files. Solving. Then Qbricks takes advantage of various means to prove the generated POs modulo our equational theories. A dedicated interface enables to directly access them and either send them to a set of automatic SMT-solvers (CVC4, Alt-Ergo, Z3, etc.
Purpose Accurate segmentation of brain resection cavities (RCs) aids in postoperative analysis and determining follow-up treatment. Convolutional neural networks (CNNs) are the state-of-the-art image segmentation technique, but require large annotated datasets for training. Annotation of 3D medical images is time-consuming, requires highly-trained raters, and may suffer from high inter-rater variability. Self-supervised learning strategies can leverage unlabeled data for training. Methods We developed an algorithm to simulate resections from preoperative magnetic resonance images (MRIs). We performed self-supervised training of a 3D CNN for RC segmentation using our simulation method. We curated EPISURG, a dataset comprising 430 postoperative and 268 preoperative MRIs from 430 refractory epilepsy patients who underwent resective neurosurgery.
We fine-tuned our model on three small annotated datasets from different institutions and on the annotated images in EPISURG, comprising 20, 33, 19 and 133 subjects. Results  The model trained on data with simulated resections obtained median (interquartile range) Dice score coefficients (DSCs) of 81. 7 (16. 4), 82. 4 (36. 4), 74. 9 (24. 2) and 80. 5 (18. 7) for each of the four datasets. After fine-tuning, DSCs were 89. 2 (13. 3), 84.
Resection cavity (RC) segmentation is also necessary in other applications. For neuro-oncology, the gross tumor volume, which is the sum of the RC and residual tumor volumes, is estimated for postoperative radiotherapy  [10]. Despite recent efforts to segment RCs in the context of brain cancer  [18, 10] , little research has been published in the context of epilepsy surgery. Furthermore, previous work is limited by the lack of benchmark datasets, released code or trained models, and evaluation is restricted to single-institution datasets used for both training and testing.
Recently, a 2D convolutional neural network (CNN) was trained to segment the RC on MRI slices in 30 glioblastoma patients  [10]. They obtained a 'median (interquartile range)' Dice score coefficient (DSC) of 84  (10)  compared to ground-truth labels by averaging predictions across anatomical axes to compute the 3D segmentation. While these approaches require four modalities to segment the resection cavity, some of the modalities are often unavailable in clinical settings  [9]. Furthermore, code and datasets are not publicly available, hindering a fair comparison across methods. Applying these techniques requires curating a dataset with manually obtained annotations to train the models, which is expensive. Unsupervised learning methods can leverage large, unlabeled medical image datasets during training.
In self-supervised learning, training instances are generated automatically from unlabeled data and used to train a model to perform a pretext task. The model can be fine-tuned on a smaller labeled dataset to perform a downstream task  [5]. The pretext and downstream tasks may be the same. For example, a CNN was trained to reconstruct a skull bone flap by simulating craniectomies on CT scans  [17]. Lesions simulated in chest CT of healthy subjects were used to train models for nodule detection, improving accuracy compared to training on a smaller dataset of real lesions  [25].
Contributions We present a self-supervised learning approach to train a 3D CNN to segment brain RCs from T 1 -weighted (T 1 w) MRI without annotated data, by simulating resections during training. We ensure our work is reproducible by releasing the source code for resection simulation and CNN training, the trained CNN, and the evaluation dataset. To the best of our knowledge, we introduce the first open annotated dataset of postoperative MRI for epilepsy surgery. This work extends our conference paper  [22]  as follows: 1) we performed a more comprehensive evaluation, assessing the effect of the resection simulation shape on performance and evaluating datasets from different institutions and pathologies; 2) we formalized our transfer learning strategy.
Problem statement The overall objective is to automatically segment RCs from postoperative T 1 w MRI using a CNN f θ parameterized by weights θ. Let X post : Ω → R and Y cavity : Ω → {0, 1} be a postoperative T 1 w MRI and its cavity segmentation label, respectively, where Ω ⊂ R 3. X post and Y cavity are drawn from the data distribution D post. In model training, the aim is to minimize the expected discrepancy between the label Y cavity and network prediction f θ (X post ). Let L be a loss function that estimates this discrepancy (e. g. , Dice loss). The optimization problem for the network parameters θ is: θ * = arg min θ E Dpost [L (f θ (X post ) , Y cavity )] (1) In a fully-supervised setting, a labeled dataset D post = {(X post i , Y cavity i )} npost i=1 is employed to estimate the expectation defined in  (1)  as: E Dpost [L (f θ (X post ) , Y cavity )] ≈ 1 n post npost i=1 L(f θ (X post i ), Y post i ) (2) In practice, CNNs typically require an annotated dataset with a large n post to generalize well for unseen instances.
Simulation for domain adaptation and self-supervised learning Let D pre = {X pre i } npre i=1 be a dataset of preoperative T 1 w MRI, drawn from the data distribution D pre. We propose to generate a simulated postoperative dataset D sim = {(X simi , Y simi )} nsim i=1 using the preoperative dataset D pre. Specifically, we aim to build a generative model φ sim : X pre → (X sim , Y sim ) that transforms preoperative images into simulated, annotated postoperative images that imitate instances drawn from the postoperative data distribution D post. D sim can then be used to estimate the expectation in (1): E Dpost [ L (f θ (X post ) , Y cavity )] ≈ 1 n sim nsim i=1 L(f θ (X simi ), Y simi ) (3) Simulated images can be generated from any unlabeled preoperative dataset. Therefore, the size of the simulated dataset can be much greater than the annotated dataset D post , i.