dataesr/scientific-paragraphs-categorization huggingface dataset:
For a small dataset such as Caltech-7 ( n = 1474 ), the number of anchors may be upper bounded. Therefore, an experimental extension is achieved and   the numerical perturbation problem is solved by simply reducing the number of selected anchors to less than 10 0 0 anchors, where m = 700 anchors are experimented and validated (see Fig. 4  ). Figure  5  illustrates the clustering performance as a function of the number of anchors using the Scene-15 dataset. As can be seen, the clustering performance can be affected by this number. The accuracy varies between 0. 4939 ( m = 400 ) and 0. 56 6 6 ( m = 700 ). There are no specific criteria for determining the optimal number of anchors, but we can admit that this depends strongly on the number of samples. As an example for Scene-15, if the number of anchors is less than 500 a degradation in clustering performance is observed.
Comparison with state-of-the-art multi-view methods To validate the superiority of the proposed algorithm, we performed extensive experiments with 11 state-of-the-art comparison methods. Table  7  shows the performance of all the competing clustering methods for the four datasets. In this table, the best clustering performance is highlighted in bold. According to Table  7  , the OMSC method shows unbalanced performance, noticeable at extremely low ACC, in contrast to the superior NMI and Purity for all datasets; this approach may require special adjustment. Based on the results depicted in Tables  4  and 7  , we can draw the following observations. Analytically, the SMVSC and LMVSC methods require quite a long runtime, but have the second best results. This is due to the smooth representation task achieved by the graph filtering in SMVSC and the anchor graph technique in LMVSC.
In terms of general clustering metrics, most baselines perform better than other competing methods for a given dataset. For example, BMVC is better for large datasets such as NUSWIDE-Obj. WMSC is better for the Scene-15 dataset, NESE for Caltech101-20, and GMC for Caltech101-7. We can deduce that AW-BMVC achieves superior performance on the four benchmark image datasets: Caltech101-7, Caltech101-20, NUS-WIDE-obj, and Scene-15 in three evaluation indices and outperforms the results of the other methods.
Empirical results on several well-known datasets have confirmed the superiority of our approach over considerable state-of-the-art multi-view clustering methods. However, for the scientific integrity of the proposed approach three unavoidable accompanying flaws must be mentioned: (1) It is pretty obvious as long as the preferred number of anchors is fixed to 10 0 0 samples, the thing that makes the model selective as it doesnt deal with datasets any less. (2) Despite the effort s to make the model autonomously learn view and sample weights, we still have the weary manually tunable regularization parameters( β, γ , λ) for its stability, on which the clustering performance is highly dependent. (3) The choice of pre-trained deep Vgg16 as a part of binary matrix initialization technique restricts the scope of evaluation for handling only image datasets.
Data analysis Localization accuracy was assessed based on 3 angular error metrics calculated between the actual source locations and participants responses, as well as the rate of localization reversal errors. Great circle angle error was calculated as the central angle of the two vectors originating from the center of the listener's head during the response aimed towards the source and the indicated locations, respectively. Because great circle angle only provides a magnitude of error, the lateral angle error and polar angle error were computed, using the interaural coordinate system. The lateral and polar errors are the signed difference between the lateral and polar angles of the target and the participant response. Since polar angle error becomes distorted at the poles of the coordinate system  [13] , a 0.
Acknowledgments This study received approval from the  Comité d'Éthique de la Recherche, Sorbonne University , project number  CER-2021-094. This work was carried out in the context of the  SONICOM  project (https://www. sonicom. eu/www. sonicom. eu)that has received funding from the  European Union 's  Horizon 2020 research and innovation program  under grant agreement No. 101017743. We wish to thank  Dr. Brian F. G. Katz  who provided insight and expertise that greatly assisted the research and improved the manuscript.
Introduction and motivation In this paper we lower the amount of manual work one needs to do in order to reuse formal libraries. All modern libraries are organized around interfaces for which the user is expected to provide an instance. For example the ssreflect component of the Mathematical Components library is based on the eqType interface, that stands for types equipped with an equality test. In order to use that library in the development of the Jasmin compiler  [2] [3] [4] , we need to provide an equality test (and its soundness proof) for each and every data type. As of today most of these eqType instances are built by hand. In this paper we develop the feqb tool which is able to synthesize automatically these instances in practice. In order to achieve this, we overcome the following difficulties.
Specification We build our tool feqb on top of Coq-Elpi which lets one implement Coq commands (or tactics) in Elpi, a dialect of 𝜆Prolog. This programming language is well suited to manipulate syntax trees which contain binders and provides Higher Order Abstract Syntax (HOAS) data types. Figure  3  shows the HOAS of inductive data types handled by feqb. I represents a definition of a Coq inductive type. tparam stands for the typical parameter of containers, like the A in list A. Since we use HOAS, its argument is a function that binds a type expression (of type E) in the rest of the inductive definition. vparam stands for parameters which are not types but rather values, like size in word size; similarly it binds that value in the rest of the declaration. The last constructor of I, inductive, encodes the declaration of the constructors.
Implementation and benchmarks The implementation consists of around 800 lines of Elpi code, organized as follows: It is out of scope to describe all the code of feqb in the present paper, nevertheless we give a taste of it presenting the rules for synthesizing eqb_fields in Figure  5. The code is divided into two procedures: Γ, 𝜎 ⊢ i | 𝐼 j | 𝐽 𝜆 B and Γ, 𝜎 ⊢ X 𝑠 | 𝐴 Y 𝑠 | 𝐵 ∧ C. The former generate abstractions corresponding to the parameters of the inductive type, while the latter builds the code corresponding to the conjunction of equality tests that compares the fields of constructors. Γ is a context which contains rules linking two types t and s to their equality test f (of type t -> s -> bool) : t ? = s ↦ → f. We expect it to contain rules for known eqTypes, that is type for which feqb has previously synthesized the equality test, for example: Γ ⊃                nat ? = nat ↦ → nat_eqb ∀𝑛 𝑚, word 𝑛 ? = word 𝑚 ↦ → word_eqb 𝑛 𝑚 ∀𝑎 𝑏 𝑓 , 𝑎 ? = 𝑏 ↦ → 𝑓 =⇒ list 𝑎 ? = list 𝑏 ↦ → list_eqb 𝑎 𝑏 𝑓                Remember that we build heterogeneous equality tests when the types have value parameters, such as word.
It is only after eliminating unrelated slowdowns from Coq-Elpi (on which feqb is based) that we could sample the real complexity. And we think that there is still a lot of room for improvement in both the code of Coq-Elpi and feqb. This engineering work is an additional contribution of the current paper and also explains why Coq-Elpi's derive is, in spite of being quadratic, faster than the alternatives. We believe some engineering work could make the other tools show their actual complexity bound. For example Deriving is a reflexive procedure, it does not really generate an equality test, but it rather provides a program that given a first class description of an inductive data type generates the test, together with its proof. It is totally unclear to us why it does not scale to large inductives.
INTRODUCTION Cryptographic proofs can be challenging to make fully precise and to rigorously check. This has caused a "crisis of rigor"  [30]  in cryptography that Shoup  [89] , Bellare and Rogaway  [30] , Halevi  [59] , and others, proposed to address by systematically structuring proofs as sequences of games. This game-based proof methodology is not only ubiquitous in provable cryptography nowadays, but also amenable to full machine-checking in proof assistants such as Coq  [26, 78]  and Isabelle/HOL  [27]. It has also led to the development of specialized proof assistants  [21, 35]  and automated verification tools for cryptographic proofs  [19, 25, 35]. There are two key ideas behind these tools: (i) formally representing games and the adversaries against them as code in a probabilistic programming language, and (ii) using program verification techniques to conduct all game transformation steps in a machine-checked manner.
For a long time however, game-based proofs have lacked modularity, which made them hard to scale to large, composed protocols such as TLS  [83]  or the upcoming MLS  [17]. To address this issue, Brzuska et al. [40]  have recently introduced state-separating proofs (SSP), a methodology for modular game-based proofs, inspired by the paper proofs in the miTLS project  [33, 34, 55] , by prior compositional cryptography frameworks  [43, 71, 72] , and by process algebras  [74]. In the SSP methodology, the code of cryptographic games is split into packages, which are modules made up of procedures sharing state. Packages can call each other's procedures (also known as oracles) and can operate on their own state, and adversarial packages in particular cannot directly access other packages' state. Packages have natural notions of sequential and parallel composition that satisfy simple algebraic laws, such as associativity of sequential composition.
Importantly, we show a formal connection between these two proof styles in Theorem 2. 4. SSProve is a foundational framework, fully formalized in Coq. To achieve this, we define the syntax of cryptographic pseudocode in terms of a free monad, in which external calls are represented as algebraic operations  [79]. This gives us a principled way to define sequential composition of packages based on an algebraic effect handler  [81]  and to give machine-checked proofs of the SSP package laws  [40] , some of which were treated informally on paper. We formalize the state of SSP packages in terms of a shared global memory and make precise the minimal state-separation requirements, by only requiring disjoint state between adversaries and the games with which they are composed. Beyond syntax, we also give a denotational semantics to cryptographic code in terms of stateful probabilistic functions that can signal assertion failures by sampling from the empty probability subdistribution.
[40]  used to illustrate the main ideas of SSP. The proof extensively uses the package laws of SSP and showcases formal reasoning with invariants. Second, we give a new proof of security of Σ-protocols in SSP style, and show how any Σ-protocol can be used to construct a commitment scheme, which allows us to compare with a similar development in CryptHOL  [42]. We instantiate the general security proof for Σ-protocols to the concrete example of Schnorr's Σ-protocol  [87]  to derive concrete security bounds. We have already started to reap the benefits of mechanizing SSP in a proof assistant: our mechanization of the KEM-DEM proof of Brzuska et al. [40]  has led us to find-in conjunction with  Brzuska et al. -an error in their originally published paper proof. Brzuska et al. have since proposed a revised version of their theorem and proof, which we have adapted and fully mechanized in SSProve.
In turn, Markulf Kohlweiss has alerted us about a weakness in the security definition of public-key encryption schemes used in the conference version of the current paper  [1] , which we quickly fixed as discussed in §2. 4. This demonstrates that the language of SSProve is comprehensible to independent experts, who can review security definitions. Outline. The remainder of this paper is structured as follows. §2 illustrates the key ideas of how to use SSProve on two simple cryptographic proofs, showing semantic security of PRF-based and ElGamal encryption. In §3 we formalize the SSP methodology: cryptographic pseudocode, packages, sequential and parallel composition, and the algebraic laws they satisfy. In §4 we introduce the rules of a probabilistic relational program logic and use them to prove Theorem 2.
4, which formally connects SSP to this program logic. In §5 we outline the effect-modular semantic model we use to prove the soundness of the program logic. In §6 we present a first larger case study, formalizing security of the KEM-DEM public key encryption scheme of Cramer and Shoup  [48] , following the proof of Brzuska et al. [40]. In §7 we present the formalization of Σ-protocols in SSProve as a second case study. Remark. A previous version  [1]  of the present paper has been published at CSF 2021. The improvements we made throughout the text are too many to list exhaustively. At a high level we: (i) corrected the ElGamal security definition in §2. 4; (ii) expanded the explanation of the logical rules in §4 and added new rules for assertions, one-sided memory accesses, and state invariants; (iii) significantly expanded the semantics section to be more self-contained and accessible, and to draw connections to related approaches ( §5); (iv) added Sections 6 and 7 presenting two new case studies; and (v) improved and expanded the related work section ( §8).
USING SSPROVE: KEY IDEAS AND EXAMPLES Formalizing the SSP methodology for high-level proofs allows us to formally link it to the methodology of probabilistic relational program logics for low-level proofs. In this section, we begin with a brief introduction to SSP ( §2. 1). Then, we present our new theorem connecting SSP to a probabilistic relational program logic ( §2. 2). Finally, by way of two examples, we show how the two methodologies are used together to obtain machine-checked security proofs. The first example looks at a symmetric encryption scheme built out of a pseudo-random function ( §2. 3), while the second looks at ElGamal, a popular asymmetric encryption scheme ( §2. 4).
Proving perfect indistinguishability steps in a probabilistic relational program logic We now present the main novel result brought by SSProve. The SSP laws above deal only with the high-level structure of composed packages. However, we often also need to show that two concrete games are equivalent with respect to what an adversary can learn from using them, i. e. , perfect indistinguishability. In SSProve we formally verify this kind of equivalence by reducing it to proving a family of semantic judgments in a probabilistic relational program logic. The logic we use is a variant of pRHL, a probabilistic relational Hoare logic introduced by Barthe et al. [26]  in CertiCrypt. Judgments of this logic are of the form ⊨ { { {(𝑚 0 , 𝑚 1 ). 𝜙} } } 𝑐 0 ∼ 𝑐 1 { { {(𝑚 ′ 0 , 𝑎 0 ), (𝑚 ′ 1 , 𝑎 1 ). 𝜓} } } and intuitively mean that after separately running the two code fragments 𝑐 0 and 𝑐 1 on the corresponding component of a pair of memories 𝑚 0 , 𝑚 1 satisfying a precondition 𝜙, the final memories 𝑚 ′ 0 , 𝑚 ′ 1 and results 𝑎 0 , 𝑎 1 satisfy the postcondition 𝜓.
Security proof of PRF-based encryption in SSProve We first illustrate the key ideas of SSProve on a cryptographic proof by Brzuska et al. [40]  that we have verified in Coq using our framework. In this proof, reasoning about composed packages (using Lemmas 2. 2 and 2. 3 above) allows for a high level of abstraction that drives the proof argument. Some steps of this proof are, however, justified by perfect indistinguishability between games, which involves inspecting the procedures of the games and applying program transformations to show the equivalence. In the previous paper proof  [40]  these steps were only justified informally by code inspection. Instead, we have formally verified these steps too, using Theorem 2. 4 and our relational program logic. Brzuska et al. [40]  show how to construct a symmetric encryption scheme out of a pseudo-random function (PRF) and use the SSP methodology to reduce security of the encryption scheme-expressed as IND-CPA-to the security of the pseudo-random function, expressed as being indistinguishable from a package doing random sampling.
Our formalization only considers the case in which the adversary can see a single ciphertext (one-time CPA, written OT-CPA), as it is known that this suffices for public-key encryption schemes to satisfy CPA  [86, Claim 15. 5]. We leave the formalization of this last result as future work and discuss hereafter our proof of OT-CPA in SSProve. The security property OT-CPA is expressed in terms of the advantage against game pair CPA 01 in Figure  11. An adversary A can call Get_pk() and get the public key, if already initialized. 4  The adversary can "challenge" a package to encrypt a certain plaintext msg through Challenge(msg). Both packages return a ciphertext only if the counter is 0-as expressed by the use of assert-so the adversary can only see one ciphertext. Both packages call KeyGen to generate public and private keys, but while CPA 0 indeed encrypts the message provided by the adversary with the public key through Enc(pk, msg), the package CPA 1 instead returns a randomly sampled ciphertext was not a proper public-key scheme.
FORMALIZING STATE-SEPARATING PROOFS We separate the programming language and thus the reasoning into two strata: code and packages. We define the syntax of code ( §3. 1), relate it to the notation used in §2. 1, and explain its semantics ( §3. 2). We then give a formal description of packages ( §3. 3) and the algebraic laws they obey ( §3. 4). In §2. 1 we took some license regarding notation in order to stay close to the presentation of Brzuska et al. [40]. The code examples in the remainder of the paper more faithfully follow the Coq notations we use in the formal development of SSProve.
Syntax for cryptographic code (free monad) The language of the Coq system, Gallina, is a dependently typed, purely functional programming language. As such, we can directly express functional code in Gallina, but not code with side-effects such as reading from and writing to memory, probabilistic sampling, or external procedure calls. We thus represent cryptographic code via a combination of the ambient language Gallina and a monad of effectful computations. Monads constitute an established way of adding effects to a purely functional language  [76, 97]. Free monads in particular allow to separate the representation (syntax) of an embedded language from its interpretation (semantics). Raw code. We use a hybrid approach  [78]  of embedding the pure fragment of our cryptographic programming language shallowly in Coq, and embedding the effects deeply via a free monad.
The type assigned to ℓ is denoted by type ℓ. Continuations. A continuation is a suspended computation awaiting the result of an operation, intuitively corresponding to the rest of the program. Consider for instance the code (2). The get operation performs a memory lookup at the location ℓ, and its continuation is a Coq function "(λ x ℓ. put. ) " of type "type ℓ → raw_code nat" that receives the value stored at ℓ as its parameter 𝑥 ℓ. The continuation in turn performs a put operation, storing the value 𝑥 ℓ + 1 at memory location ℓ, and returns the value 𝑥 ℓ. The code thus corresponds to the expression written as ℓ++ in common imperative languages. Variables. As demonstrated in example (2), we draw a strict distinction between a location ℓ, which can be accessed and updated via get and put, and the value stored in memory at location ℓ.
bind ( 𝜅 ' v ) 𝜅 ) | put l v 𝜅 ' ⇒ put l v ( bind 𝜅 ' 𝜅 ) | sample op 𝜅 ' ⇒ sample op ( λ a. bind ( 𝜅 ' a ) 𝜅 ) end An easy structural induction over code allows us to prove that bind satisfies the expected monad laws: bind is associative (bind m (λ p. bind (f p) g) = bind (bind m f) g), and return serves as a unit (bind (return x) f = f x and bind m return = m). Loops. We do not have syntax for loops in code. However, since we are embedding in Coq we take advantage of its recursion mechanisms to write terminating loops. The most basic construction we can write is a "for i := 0 to N do c" loop that repeats (N+1)-times a command c, providing to c the value of the index i. In the code below, the pattern matching happens over the natural number N, which in Coq is represented in unary format, so it is either 0 (zero) or S n (read successor of n, for some natural number n).
Definition fail A : code A : = x ← sample dnull ; return x. A simple assertion is not expected to produce any interesting values but only gets evaluated for the possibility of failing if the condition is violated. This is expressed by the fact that a successful assert simply returns a value of unit type, where unit is Coq's singleton type with a unique inhabitant (). Definition assert ( b : bool ) : code unit : = if b then return ( ) else fail unit. If b is true, then assert returns the trivial value () , but if b is false, we instead sample from the dnull subdistribution via fail unit, assigning probability zero to all values of the type unit (i. e. , to () ). Sampling from the null subdistribution is similar to non-termination, and means that the continuation will never be called. This provides a simple and clearly defined semantics for assertion failures.
Operationally assertD is similar to the simple assert above, but the actual Coq definition in terms of fail and a conditional is more complicated because it uses dependent elimination to type-check the success branch. Since such details are not important here, we refer the interested reader to the Coq source and only show the type of this operator: Definition assertD A b ( kont : b = true → code A ) : code A. Procedure calls. A call to an external procedure such as Prf in (3) is represented by the call operation, taking as arguments a procedure name p annotated with a type, a value matching the argument type of p, and a continuation 𝜅 matching the return type of p. In §3. 3 we show how an implementation gets substituted for this placeholder via sequential package composition. Notation. The use of continuations is pervasive in monadic code, and to alleviate the presentation we introduce the following more familiar notation.
Semantics of cryptographic code When no external procedure calls (call o x k) appear in a piece of code c : code A, it is possible to interpret c as a state-transforming probability subdistribution of type Pr_code c : mem → SD ( A × mem ) This semantics is similar to that of CertiCrypt  [26]. The type SD A denotes the collection of all subdistributions over type A. Generally speaking, a subdistribution is a function 𝑑 : 𝐴 → R assigning a certain probability 𝑑 (𝑎) to each 𝑎 : 𝐴 in such a way that ∫ 𝐴 𝑑 ≤ 1. We use the definition of subdistributions from mathcomp-analysis  [4, 69] , a Coq library from which we use the foundations it gives to discrete probability theory. The semantics function Pr_code is defined by recursion on the structure of c. Its definition basically boils down to providing an effect handler that interprets state and probabilities in the monad mem → SD(-× mem).
[22]. In the remainder of this subsection we describe a selection of our rules. The presentation does not contain all the rules employed in practice by SSProve, nor does it provide a canonical presentation of these rules: some rules are overlapping hence there are multiple ways to prove the same relational judgment, but the actual derivation might be simpler with this redundancy. We return to the question of the organization of rules after this presentation. 𝑐 : code L 𝐴 ⊨ { { {𝑚 0 = 𝑚 1 } } } 𝑐 ∼ 𝑐 { { {(𝑚 ′ 0 , 𝑎 0 ), (𝑚 ′ 1 , 𝑎 1 ). 𝑚 ′ 0 = 𝑚 ′ 1 ∧ 𝑎 0 = 𝑎 1 } } } reflexivity The reflexivity rule relates the code 𝑐 to itself when both copies are executed on identical initial memories. 𝑐 0 : code L 0 𝐴 0 𝑐 1 : code L 1 𝐴 1 𝜅 0 : 𝐴 0 → code L 0 𝐵 0 𝜅 1 : 𝐴 1 → code L 1 𝐵 1 ⊨ { { {𝜙} } } 𝑐 0 ∼ 𝑐 1 { { {𝜒} } } ∀𝑎 0 𝑎 1.