dataesr/scientific-paragraphs-categorization huggingface dataset:
e. , copying) is restricted. On the other hand, when doing classical computation, such restrictions are unnecessary and often inconvenient. One solution to this problem is to design a language with a classical (non-linear) fragment together with a quantum (linear) one, both of which interact nicely with each other. In fact, this can be achieved within an existing language that has a sufficiently advanced type system, as we show in this paper. In this paper, we describe Qimaera (named after the hybrid creature Chimaera from Greek mythology), which is a set of libraries for the Idris 2 language  [10]  that allow the programmer to implement hybrid quantum-classical algorithms in a type-safe way. Idris 2 is an elegant functional programming language that is equipped with an advanced type system based on Quantitative Type Theory  [24, 6]  that brings many useful features to the programmer, most notably dependent types and linearity.
We emphasise that we can achieve type-safe hybrid quantum-classical programming in an existing programming language by implementing suitable libraries. This is important for variational quantum programming, because in most variational quantum algorithms, the classical part of the algorithm is considerably larger, more complicated and more difficult to implement, compared to the quantum part of the algorithm. Therefore, it is important for the programming language to have first-class support for classical programming features. We think our chosen language, Idris, is such a language. The advanced type system of Idris allows us to elegantly mix quantum and classical programming primitives and therefore allows us to achieve our objectives. We demonstrate that Qimaera is suitable for variational quantum programming by providing implementations of the two most prominent variational quantum algorithms -QAOA and VQE.
Why Idris instead of another language? The features that we require to achieve our objectives are: general recursion, dependent types and linearity. We chose Idris 2, because it is an excellent language that has all three of these features. Removing general recursion limits the expressivity of the language (as explained above). The other two features are used to reject erroneous quantum programs. We think that most programming languages that have the three features mentioned above are suitable for type-safe hybrid quantum-classical programming. In fact, one of the main points that we wish to demonstrate with this paper is that it is not necessary to build a standalone programming language in order to achieve the desired safety properties. Instead, the same can be achieved with already existing languages, such as Idris 2.
Background on the Idris 2 Language In this section, we give a short overview of the Idris 2 language and its main features that are relevant for the development of Qimaera. Idris 2 is a functional language with a syntax influenced by that of Haskell. The features of particular interest for us are dependent types and linearity, both of which are crucial for Qimaera. Its type system is based on Quantitative Type Theory  [24, 6] , which specifies how dependent types and linearity are combined. Dependent Types. In Idris, types are first-class primitives and they may be manipulated like other constructs of the language. This allows us to formulate more expressive types that can depend on values, and hence it enables us to make some properties and program invariants explicit. Example 1. The type of vectors is a simple and useful example of a dependent type.
append : Vect n a -> Vect m a -> Vect ( n + m ) a This information allows the language to detect a larger class of programming errors. Note that type dependency information is not available for the analogous function on lists. Type dependency may also be used to express constraints on the inputs of a function, e. g. , we can define a total function, called pop, that cannot be applied to an empty vector. Writing "pop []" is now an error which is detected statically, rather than dynamically, and we note that the same cannot be achieved if we were to replace vectors with lists. Linearity. The type system of Idris 2 is based on Quantitative Type Theory, where every function argument is associated with a multiplicity that states the number of times the variable is used at runtime 5. This multiplicity can be 0, 1 or ω.
Unitary Operations in Qimaera We describe our representation of unitary transformations in Qimaera as an algebraic data type called Unitary. Every value of this type is, by design, an algebraic decomposition of a unitary operation in terms of the atomic unitary gates that we selected in §2. The Unitary data type allows us to adopt a high-level algebraic and scalable approach towards the reversible fragment of quantum computation. This provides the programmer with some benefits as we show in this section. However, using the Unitary data type is actually entirely optional. Users who are interested in effectful quantum programming do not have to use it (see §5) and they may still do hybrid classical-quantum programming, but at the cost of losing the algebraic decomposition of unitary operations.
This is best understood by example. Example 6. Consider the following code sample: Adjoints of Unitary Circuits. Qimaera also provides a function adjoint : Unitary n -> Unitary n which computes the adjoint (i. e. , inverse) of a given unitary circuit. One often has to apply the inverse of a given unitary circuit, so having a method such as this one is useful. Our implementation uses the standard approach for synthesising the adjoint. The adjoint may be used, for example, to uncompute the result of the application of unitary gates on auxiliary qubits. Controlled Unitary Circuits. We also implement a function controlled : { n : Nat } -> Unitary n -> Unitary ( S n ) which given a unitary circuit U constructs the corresponding controlled unitary circuit CU. Our implementation uses the standard and simple algorithm for doing this, but more efficient algorithms may also be implemented in principle.
Example: The Quantum Fourier Transform The Quantum Fourier Transform (QFT) is an important unitary operator that is used in Shor's polynomial-time algorithm for integer factorisation  [34]. The unitary circuit which realises QFT on n qubits is shown in Figure  4 , where R n def = P 2π 2 n. The Qimaera code which implements this unitary circuit is shown in Figure  5. Notice that we make use of the controlled function from §4. 2 in the function cRm, so that we can implement the controlled R n gates that are required. In this example, we have parameters that are universally quantified, so we need a few proofs in the code: one for using the apply function and one for correctly unifying the size of the circuit. These proof obligations appear when writing the qftRec function and Idris did not infer them automatically, so we had to provide the proofs.
Representation of Quantum Effects in Qimaera We now explain how the quantum program dynamics are represented in Qimaera in a type-safe way. We are (roughly) inspired by representing the notion of a quantum configuration as it appears in  [32, 29, 22] , which is in turn used to formally describe the operational semantics of quantum type systems. Qubits in Qimaera. Because of the possibility of quantum entanglement, we cannot describe the state of an individual qubit which is part of a larger composite system. On the other hand, we wish to be able to refer to parts of the whole system by identifying specific qubit positions. In Qimaera, we introduce the following type declaration: The argument of type Nat is used as a unique identifier for the constructed qubit. The constructor MkQubit is private and users of our libraries cannot access it (outside of the library file).
Terms of type Qubit do not carry any sort of linear-algebraic information. Probabilistic Effects. Quantum measurements induce probabilistic computational effects which are inherited by the classical side of the computation in hybrid classical-quantum algorithms. Furthermore, in our intended computational scenario, the classical computer (on which Idris is running) sends instructions to, and receives data from, the quantum device. In order to correctly model all of this, it is clear that we have to use the IO monad in order to encapsulate these effects. However, when representing quantum program dynamics, we also need to enforce linearity, but all the functions provided by the IO monad (e. g. , pure which introduces pure values to monadic types) are not linear in any of their arguments. This creates a problem which may be solved by using the LIO library, which extends the IO monad with linearity.
For example, if in the above code we replace the last two statements in the run environment with "pure True", then Idris statically detects this error. The function coin from Example 7 is implemented using our abstract interface. This means we can use this function in any concrete implementation of the QuantumOp interface. Since the authors do not have any quantum hardware, we provide one concrete implementation of this interface, called SimulatedOp, which performs linear-algebraic simulation of all the required operations. For example, if we wish to use the coin function, then the code: testCoin : IO Bool testCoin = coin { t = SimulatedOp } defines a new function, called testCoin, which does the same as coin, but it specifically instructs Idris to use linear-algebraic simulation. We emphasise that all of our quantum algorithms are written using our abstract interface, so there is no need to reimplement them for any additional concrete implementations of the interface.
Note that this is an algorithmic realisation of U , not an algebraic one, and so we cannot write a program of type Unitary that achieves this. Instead, we represent this as a quantum program in Figure  8. There, RUS q u' e is the quantum state transformer which implements the RUS algorithm as above. The function runRUS simply executes the RUS algorithm on a qubit in state |0 , with the unitary operator chosen from  [27, Figure 8] , then measures the qubit and returns the outcome. Both of these functions are written using our abstract interface. The function testRUS is the same as runRUS, but it also instructs Idris to use linear-algebraic simulation for the execution. Note that, in our implementation, we have taken a specific instance of RUS by choosing U to be the unitary operator described by example u' as discussed in  [27, Figure 8 ].
Variational Quantum Programming In the previous section we saw that Qimaera is suitable for writing recursive and effectful quantum programs that make use of quantum measurements. Moreover, Idris 2 is an excellent programming language with an advanced type system and first-class support for classical programming features. In order to demonstrate that Qimaera is suitable for hybrid classical-quantum programming, we also have to show that both classical and quantum programming features may be elegantly combined. This is the purpose of this section and we achieve this by implementing the two most prominent variational quantum algorithms: the Quantum Approximate Optimization Algorithm (QAOA)  [13]  and the Variational Quantum Eigensolver (VQE)  [30]. In this paper we only describe QAOA. See the full paper  [12]  for more information on the implementation of VQE.
Related Work In this section we compare Qimaera with other existing quantum programming languages that are implemented in software. We omit comparisons with quantum type systems that do not have a software implementation. We provide a feature comparison with some quantum programming languages in Table  2  and we now clarify the meaning of some of the selected features. By Type Safety we mean that the language can statically detect (and reject) erroneous programs which duplicate quantum data. General Recursion is the ability to express recursive (possibly non-terminating) programs and almostsurely-terminating programs, such as RUS (see §5. 2). Measurements is the ability to use the outcomes of quantum measurements in the control flow of programs. Promotion of Measurements is the ability to integrate the outcomes of quantum measurements as a native classical type (e.
Both of these languages have access to dependent types, courtesy of Coq. The focus of these languages is mostly on verification, whereas in Qimaera we focus on programming and Idris 2 has better support for classical, quantum and effectful programming features compared to Coq. Both QWIRE and SQIR represent quantum primitives through the use of low-level specification languages that are embedded in Coq: both of these specification languages lack the ability to express quantum algorithms that require general recursion and both of them lack the ability to express quantum higher-order functions. Because of the former reason, the RUS algorithm from §5. 2 cannot be expressed in QWIRE or SQIR. Silq  [9]  is a standalone quantum programming language which also is typesafe and whose main notable feature is automatic uncomputation of temporary values.
We currently partially support this feature, because we have clearly identified and separated the reversible fragment of quantum computation (see the Unitary type) and we can synthesise the required adjoints by calling the adjoint function. Compared to Silq, the main advantage of Qimaera is that Idris has better support for classical programming features and so we believe that Qimaera is a better choice for hybrid classical-quantum programming. In addition, Silq does not support general recursion, so it cannot express quantum algorithms that rely on this (e. g. , RUS §5. 2). Quipper  [18]  and the Quantum IO monad (QIO)  [3]  are two domain specific languages (DSLs) embedded in Haskell. Neither of them are type safe because they do not utilise linearity and they cannot statically detect quantum programs that are physically inadmissible.
Language Another recent language includes Proto-Quipper-D  [14]  which is a type-safe circuit description language. This language is based on a novel type system which shows how linearity and dependent types can be combined. A fundamental difference between Proto-Quipper-D and Qimaera is that linearity is the default mode of operation in Proto-Quipper-D, whereas in Qimaera the default mode is non-linear. The focus in Proto-Quipper-D is on circuit description and generation and the language currently lacks effectful quantum measurements and probabilistic effects, so it cannot be used for variational quantum programming at present. Another related language is Proto-Quipper-Dyn  [15]. It is similar to Proto-Quipper-D, but it lacks dependent types (which Qimaera has). On the other hand, it can handle quantum measurements and has dynamic lifting, i.
e. , the ability to parameterize quantum circuits based on information observed from quantum measurements. Note that Qimaera also has dynamic lifting. Other languages, include Google's Cirq  [17]  (a set of python libraries), IBM's Qiskit  [2]  (a set of python libraries) and Microsoft's Q  [35]  (standalone). These languages offer a wide-range of quantum functions and features, however, none of them are type-safe. Qimaera does not have this problem and this is indeed its main advantage over them, together with dependent types.
Future Work For future work, it would be interesting to consider methods that would allow us to reduce some of the proof obligations that are imposed by the Unitary data type. Going beyond Idris and our library, another natural direction is to consider whether programming languages that support substructural approaches other than linearity (e. g. , uniqueness types, ownership) can be used to achieve type-safe quantum programming. It would also be interesting to consider the relevance of arrows  [21, 5]  in quantum programming. Furthermore, implementing and testing our abstract interface on an actual hybrid quantum-classical hardware environment would most likely bring additional challenges.
Acknowledgements. We thank  Robert Rand  for discussions about this paper. We also thank the anonymous referees for their feedback which lead to multiple improvements of this paper. EJ is supported by the  PEPR  integrated project  EPiQ  and the  European Project NEASQC  (Grant Agreement  951821 ). Most of the work was done in LORIA/Inria Nancy during an Inria internship of the first author who was a student at  École polytechnique. The first and last authors have changed affiliations since then.
Thus, the use of SDSs alone to characterize the products' hazards could be considered as a limitation because even though each user is asked to verify the adequacy and SDS updates, the method is not able to confirm their accuracy and the quality of data provided on the product's effects. This method is implemented in a software named "Seirich, " which was developed by the INRS in partnership with the French Ministry of Labor, national health insurance, and French professional organizations. In addition to the control banding chemical risk assessment, Seirich software guides users in the development and follow-up of a preventive or corrective action plan to reduce risks at work. A risk assessment is provided for fire and explosion hazards. The software also offers regulation information and good practices to guide the user in the implementation of preventive actions.
Conclusion For more than 20 years, and particularly since the coming into force of the EU CLP regulation in 2015 (for mixtures), a constant evolution of the presented method has been conducted, with several improved versions implemented in the Seirich software. This involves either considering regulatory updates, introducing ergonomic evolutions, or adding new features. Currently, this method is widely used for occupational chemical risk assessment in France with more than 30,000 users. The INRS is committed to promoting this tool and ensuring its continuous improvement. This tool represents a very important step in the risk prevention process by allowing the identification and evaluation of chemical risks to which employees are exposed in the workplace. This must be followed by the implementation of a specific prevention action plan based on the results obtained, with the aim of eliminating or reducing the identified risks as much as possible.
Data collected The data collected are the answers to the survey (Appendix 1). For each item, we asked the participant to judge the IO (named "tools" in the survey) between 1 (strongly disagree) and 5 (strongly agree). The questions are taken from  (Khatib, 2015)  and  (Kobenan, 2016). We also collected every data and documents used or produced during the PR and we made observations. At the end of each PR, we saved decisions of the group. In the Appendix 2, for each PR we have listed: "risks already placed" in the previous PR, "risks added from the initial list" (from initial training documents), risks of the previous PR that have been "moved", risks of the previous PR that have been "deleted", new risks "added" to the initial list and risks "placed" in the pictures at the end of the PR.
Acknowledgements This work is a part of the  Make Our Planet Great Again project. The funding was provided by l ' Agence National de la Recherche (ANR) of France  under the  Programme d'Investissements d' Avenir  ( ANR-18-MOPGA-003 EUROACE ) and the  French region of Occitanie. A. T. is currently funded by the  French National Center for Space Studies (CNES). The computational resources for the study were made available by the  Institute for Development and Resources in Intensive Scientific Computing (IDRIS)  and the  Grand Équipement National de Calcul Intensif (GENCI). We would like to thank the two anonymous reviewers for the constructive comments and suggestions on this paper.
Here, we describe SCI-FYsim 2 , a new end-to-end simulator package written in Python and including Fourier optics tools for its bulk optics components and complex amplitude matrix manipulation for its single-mode components. We then show some of the early results that it provides in the effort to evaluate the performance of NOTT. Nulling self-calibration  (Hanot et al. 2011; Defrère et al. 2016; Mennesson et al. 2016; Norris et al. 2020; Martinod et al. 2021 ) is a different approach that makes use of the empirical distribution of the interferometric outputs to produce a statistical inference. To our knowledge, it has never been deployed for nullers more complex than the Bracewell nullers. Considering its implications in the context of NOTT is outside the scope of this work. In Sect. 2 we describe the computation produced by SCI-FYsim before listing in Sect.
The architecture of the simulator Here, we give a short overview of the architecture of the simulator. More details on some of its components are given in the following sections. The simulator articulates around a number of modules and classes that are combined and used by a director 2 https://github. com/rlaugier/SCIFYsim class in order to compute and hold the parameters of a model observatory, instrument, and observing session. Here is a partial list: observatory holds the geometric configuration of the array, and relies on the astroplan and astropy packages to compute the location of the target in the sky at a given time, the resuling alt-azimuthal pointing, and the projection of the array along -and orthogonal to -the line of sight (see Sect. 2. 5). sources is used to compute spectra of absorption and emission of the targets, and the parasitic contribution of the earth atmosphere and optical train (see Sect.
Array geometry and source The horizontal and projected geometry of the array is handled by a separate module called observatory. This is powered by astropy and astroplan to handle the coordinates of targets, pointings, and time. It also provides convenience functions with which to locate targets by name, or identify the best night of the year to make the observations; that is, where the transit of the meridian happens in the middle of the night. The pointing of the array also informs an airmass parameter inside the sky object. This module computes the projection of the array onto the plane orthogonal to the line of sight, which is then used to compute the geometric OPD affecting the beams of each light source depending on its position (α, β) in the field of view: ãl = a l e 2 jπ(X l α+Y l β) λ , (2) where for each aperture l, a l is the amplitude collected and X l and Y l are the coordinates of the apertures projected in a plane orthogonal to the line of sight and aligned to right ascension and declination.
3. 2, the demands of a broadband nulling require the correction for a more thorough model, as in that described by  Colavita et al. (2004)  and  Absil et al. (2006). However, relevant simulations of these effects will depend on the technical solutions retained for HEIMDALLR and Baldr modules of Asgard. Colavita et al. (2004)  predicted the effect of water vapor seeing for Mauna Kea to be one-twentieth of the dry effect in the near-infrared and one-seventh at 10 µm. In this work, dynamic chromatic perturbations are neglected but they will be included in later work, based on expertise gathered from GRAV4MAT at VLTI and METIS for the ELT.
Acknowledgements. SCIFY has received funding from the  European Research Council (ERC)  under the European Union's  Horizon 2020 research and innovation program  (grant agreement  CoG -866070 ). This project has received funding from the  European Union 's  Horizon 2020 research and innovation programme  under grant agreement No  101004719. The authors wish to thank  Stephane Lagarde ,  Fatmé Allouche , and  Philippe Berio  for their helpful suggestions regarding the design of MATISSE.
1 ). For age-matched control cases, H&Estained BM samples were obtained from 15 patients who underwent an elective hip replacement surgery (n ¼ 15, mean age ± standard deviation ¼ 57 ± 13 years, sex-balanced). All patients signed a specific consent for the reuse of biological samples and clinical data in the context of our study. Trephine biopsies were collected, routinely processed, and H&E-stained between 2017 and 2021 but scanned synchronously in 2020 and 2022, reflecting a gradient in H&E contrast associated with the sample age.