dataesr/scientific-paragraphs-categorization huggingface dataset:
PROTOTYPE IMPLEMENTATION We have developed a prototype implementation of our program logic on top of EasyCrypt, a general-purpose proof assistant for reasoning about probabilistic programs, and formalized stability of the convex version of Stochastic Gradient Method and convergence of population dynamics and Glauber dynamics. • For some rules, we implement stronger versions that are required for formalization of the examples. For instance, our implementation of the [Conseq] rule supports scaling of distances. • The ambient higher-order logic of EasyCrypt is used both for specifying distributions and for reasoning about their properties. Likewise, the logic is used for defining distances, Lipschitz continuity, and affine functions, and for proving their basic properties. • We axiomatize the gradient operator and postulate its main properties.
Defining gradients from first principles and proving their properties is technically possible, but beyond the scope of the paper. Similarly, we axiomatize norms and state relevant properties as axioms. A small collection of standard facts are assumed. The formalization of the examples is reasonably straightforward. The formalization of stability for the Stochastic Gradient Method is about 400 lines; about one third is devoted to proving mathematical facts. The formalization of convergence for the population dynamics about is 150 lines, while formalization of convergence for the Glauber dynamics is about 550 lines. We have not yet interfaced current the prototype with the rich set of program transformations supported by EasyCrypt, e. g. code motion, loop unrolling, loop range splitting, which are required for the non-convex version of Stochastic Gradient Method.
This line of work is focused on non-relational properties, such as proving upper bounds on errors, whereas expected sensitivity is intrinsically relational. There has also been a significant amount of work on the relational verification of probabilistic programs. Barthe and collaborators develop relational program logics for reasoning about the provable security of cryptographic constructions  [Barthe et al. 2009 ] and differential privacy of algorithms  [Barthe et al. 2012]. EpRHL subsumes the relational program logic considered by  Barthe et al. [2009] ; indeed, one can prove that the two-sided rules of pRHL are essentially equivalent to the fragment of EpRHL where the pre-distance and post-distance are the zero function. In contrast, the relational program logic apRHL considered by  Barthe et al.
Recent work introduces quantitative masking strength  [Eldib et al. 2015 ], a quantitative generalization that measures average leakage of the programs. Similarly, the bounded moment model  [Barthe et al. 2016a ] is a qualitative, expectation-based non-interference property for capturing security of parallel implementations against differential power analyses. Current verification technology for the bounded moment model is based on a meta-theorem which reduces security in the bounded moment model to probing security, and a custom program logic for proving probing security. It would be interesting to develop a program logic based on EpRHL to verify a broader class of parallel implementations. For another example, there are formal verification techniques for verifying incentive properties in mechanism design.
These properties are relational, and when the underlying mechanism is randomized (or when the inputs are randomized), incentive properties compare the expected payoff of an agent in two executions. Barthe et al. [2015 Barthe et al. [ , 2016c] ]  show how to use a relational type system to verify these properties. While their approach is also based on couplings, they reason about expectations only at the top level, as a consequence of a particular coupling. In particular, it is not possible to compose reasoning about expected values like in EpRHL, and it is also not possible to carry the analyses required for our examples. Lastly,  Barthe et al. [2017b]  use ×pRHL, a proof-relevant variant of pRHL, to extract a product program for the Glauber dynamics. In a second step, they analyze the product program to prove rapid mixing; their analysis is performed directly on the semantics of the product program.
The glass is supported on four load cells (CZL635 Micro Load Cell (0-20 kg), Phidgets Inc. ) placed on the aluminium frame at the four corners of the table. The four load cells are individually preamplified and connected to a MIMATE module, which samples the data from these sensors at 100 Hz. It then wirelessly transmits the data to the workstation. The glass surface acts similar to a force plate used in gait analysis for detecting ground reaction force and its centre-of-pressure (COP). The glass surface, along with the television underneath, thus behaves like a simple, cost-effective and large touchscreen capable of detecting a single touch and its associated force. By measuring the load cell forces, we can determine the downward component of the total force F acting on the glass surface and the COP of this applied force (x, y).
A five-point Likert scale was used to rate different aspects of their experiences with the system. The questions were verbally translated for patients who did not have English literacy; the translations were planned to be carried out by either the participating therapist or the engineers conducting the study. Furthermore, the engineer kept a record of the number of times patients asked for assistance, along with reasons behind the call for assistance. After the completion of the study, two clinicians were also contacted to review and provide feedback about the system, based on video recordings of the therapy sessions from the five patients. It must be noted that the primary aim of this pilot study was to evaluate system usability, therefore, data related to therapy efficacy were not collected.
When training with the SITAR table or the intelligent objects, a patient's visual attention remains in and around the workspace where they are physically interacting. The third important feature of the SITAR is its fully modular architecture, which allows its different components to act with some level of autonomy when sensing and reacting to a patient's interaction. This feature makes the system very versatile, enabling the different SITAR components to be used either separately or together and, thus, gives a clinician the freedom to implement different types of therapeutic programs. For example, a simple impairment-based therapy program for training grip strength can be implemented using just the iBox, which can also provide autonomous feedback to make the training interesting for the patients.
Moreover, from a technical point of view, when two or more SITAR components are used together, they act as independent sources of information about a patient's interaction with the system; these multiple sources can be fused to obtain more accurate information. For instance, short-duration arm reaching movements between two successive touches on the SITAR table can be reconstructed using information from an IMU worn on a subject's wrist and the touch position data from the SITAR table. Whenever a subject touches the SITAR table, a zero-velocity update  39  can be carried out by incorporating the position information from the table to recalibrate the IMU and thus minimise integration drift. This design approach makes SITAR an ideal tool for quantifying natural interaction of a patient with the system.
Clinical feasibility The SITAR can be used for the assessment of a patient's sensorimotor impairments and also one's ability to perform complex sensorimotor tasks related to activities of daily living. Some of the previous work with the iKey  33  and the iBox 32 demonstrated how assessment protocols can be implemented, with the different SITAR components used individually. In this article, we presented preliminary data on the use of SITAR for the assessment of workspace with the interactive tabletop, pick-and-place of objects (with the iBox) and tactile assessment (with the AsTex Õ board), further illustrating some of the possibilities of SITAR as an assessment tool. The SITAR can be used to implement simple, quick and useful measures of sensorimotor ability, as was illustrated by the workspace estimate.
This research was supported by the  European Commission  grants  EU-FP7 HUMOUR (ICT 231554 ), CONTEST (ITN  317488 ),  EU-H2020 COGIMON (ICT 644727 ),  COST ACTION TD1006 European Network on Robotics for NeuroRehabilitation  and by a  UK-UKIERI  grant between  Imperial  and  CMC Vellore. Guarantor EB Contributorship AH, SB, NR, JK, NJ, MM and EB designed the SITAR. The assessment study was conceived and carried out by AH, SB, SG and EB. The rehabilitation usability study was conceived and carried out by SB and AD. The manuscript was written.
User Requirements In the introduction we have presented the three main high-level requirements we followed to design InfraPhenoGrid: i) the ability for users to design and exchange experiments where a very large number of tools are interlinked (handled by a workflow management system), ii) the ability for users to reproduce experiments and understand the result obtained by such experiments (handled by a provenance layer), and iii) the ability to deal with large-scale experiments involving masses of data (handled by parallel computing environments). In this subsection we provide precision on the PhenoArch users' requirements. A Transparent, Familiar and Flexible Working Environment: The classical users of the PhenoArch platform are bioinformaticians, mainly Python programmers (strongly involved in the design of Jupyter/IPython notebooks  [2, 3] ), statisicians, image analysts and more generally modelers, all closely connected to the Plant community.
Reproducibility-Friendly Infrastructure: InfraPhenoGrid is a workflow infrastructure for plant scientists to analyze their datasets and understand them. Tracking data used and produced (Provenance) as well as the exact description and environments where the tools have been executed is a crucial need and should be done following international standards of the domain. InfraPhenoGrid should thus be Reproducibility-Friendly, welcoming to any plugins to export, visualize and analyze Provenance information and more generally any tool to enhance reproducibility of experiments.
To run the workflow, the user has to select the data sets to be taken as input by the workflow at execution time. The distributed infrastructure is thus transparent for the end-user. Selecting a dataset in InfraPhenoGrid actually corresponds to sending a request to iRODS to concretely get the data (step 2). Resources have then to be allocated; this is performed by DIRAC (step 3). On each allocated worker or job, OpenAlea workflows are deployed by copying an image from iRODS so that an OpenAlea server is launched (step 4). OpenAlea servers then register to SciFloware (step 5) which is in charge to distribute computations of possible subparts of the workflow to the different OpenAlea servers (step 6). The workflow is then concretely executed on the Grid (step 7). At this stage, provenance information and all information on jobs are stored and available on iRODS.
The next subsections present with more details and discuss the choices we made on the major components of InfraPhenoGrid, namely, the OpenAlea workflow system, the SciFloware middleware and the data management and provenance layer. 3. 1. Scientific Workflow Management system: OpenAlea OpenAlea -A system targeted to the plant community. The OpenAlea scientific workflow system is a component-based architecture implemented as a set of pure Python packages  [6]. The visual programming environment and graphical user interface (GUI) is implemented using the PyQt toolkit, a Python binding to the Qt application framework. OpenAlea is portable and available on Linux, Windows, and MacOS/X. OpenAlea has been in constant use since 2004 by users of the French Plant science community but not only since the system has been downloaded 618000 times and the web site counts international 10000 unique visitors a month according to the OpenAlea web repository (https://gforge.
inria. fr). OpenAlea is distributed under a free software license (L-GPL) and maintained and developed by a group of 20 active developers from different research institutes and universities. Development is performed under a collaborative scheme with shared methodologies (best practices). Coding sprints are regularly organized by various sub-groups of developers (pair programming and test driven development) and scientists (biologists and mathematicians). OpenAlea tools (e. g. , models, workflows, components) are published and shared on the web both through the main OpenAlea web repository and through web sites of groups which use and contribute to OpenAlea without being concretely partners of the OpenAlea project 2. As a consequence, more than 60 researchers have contributed to Ope-nAlea packages, in France and internationally, published through large meta-packages (e.
g. , Alinea to simulate ecophysiological and agronomical processes and VPlants to analyze, model and simulate plant architecture and its development) to ease the installation for end-users. The strong and long-term experience of PhenoArch users and their international collaborators with both using and developing workflows in OpenAlea made us choose OpenAlea as the workflow system for InfraPhenoGrid. The main technical features of OpenAlea are described here after. Using OpenAlea (Designing workflows). From an end-user point-of-view, the first feature of OpenAlea exploited is its visual programming environment (part A of Figure  4 ) where users are provided with a set of predefined workflows and libraries of tools (part B of Figure  4 ) to be combined to form new workflows. Users can create new wrapped tools by implementing them in Python (in part C of Figure  4 ).
A middleware for parallel environments: SciFloware The choice of SciFloware. As stated in the user requirements, InfraPhenoGrid should be equipped with a system able to (i) hide the complexity of the computation and offer transparent access to data and tools for end-users, (ii) provide a flexible working environment by allowing several workflow systems to be used, (iii) be adaptable to pilot tasks both on Grid and Cloud infrastructures. Using and tuning such kind of systems remains a very difficult task. Our research groups have recently developed SciFloware, a generic lightweight middleware able to coordinate and pilot the tasks to be executed in a transparent way for the user. SciFloware is based on the Shared-data Overlay Network  [12]  (SON) which follows a Software as a Service (SaaS) model, eliminating the need to install and maintain the software and allows users to run HPC programs through graphical interfaces (e.
More precisely, SciFloware is responsible for (i) sending to workflow systems the execution of such two master sub-workflows with the right input data produced by the previous executed master workflow step, (ii) collecting output data generated at the end of each execution of the sub-workflows, and (iii) launching the execution of the last step of the master workflow with such collected data. While OpenAlea has been the first workflow system orchestrated by Sci-Floware (based on our user requirements), Galaxy  [7]  and Taverna  [8]  are currently under consideration (to play the role as "X workflow system" in Figure  6 ). Algebraic expressions in SciFloware. SciFloware uses a relational data model and an algebraic language to represent data-intensive scientific workflows  [13]. Data flows are represented as relations and workflow nodes and activities as algebraic expressions.
Using these, SciFloware can request the execution of a workflow on any workflow system server, or be notified at the end of the execution of an OpenAlea workflow. Other services manage database relationships and communication protocols. Figure  7  illustrates a case where a component manages local task executions depending on a given algebraic operator. More precisely, in Figure  7 , the Map component distributes the computation among workers (OA servers, that is, OpenAlea servers) depending on its own scheduling policy. SciFloware allows new components to be added and instantiated dynamically to extend the middleware. SciFloware Architecture. The SciFloware architecture is composed of the following components (see Figure  8 ): • Algebraic Operators. For each algebraic operator, a specific component type is associated, which can be instantiated several times during the execution of a given workflow.
• Execution Manager. The Execution Manager takes in a workflow specification and instantiates the needed components (i. e. workflows or part-of workflows), such as the algebraic components. A message is sent to trigger execution of the first workflow component. The Execution Manager also manages and runs the available OpenAlea servers. At each registration of an instance of an OpenAlea server, a worker component is added to the list of available workers. • Data Manager. The Data Manager provides workers with access to the storage database. Implementation of SciFloware. The implementation of SciFloware is based on the Shared-data Overlay Network (SON)  [12] , written in JAVA, fully integrated into the Eclipse environment and implemented on top of OSGi 4. The communication protocol between SciFloware and scientific workflow systems being run on different workers use a REST (Representational State Transfer) interface.
The RESTfull communication protocol is used to register new workers, exchange the workflow specification and the data identifiers stored on iRODS and start and stop the execution. Each service in Sci-Floware is described using description files similar to the Web Service Definition Language (WSDL). Each SciFloware component has an associated description file defining the required and provided services. SON is used for the internal composition of SciFloware components. SON allows to build an application following the SAAS model (Software as a Service) using a set of components that can be executed in a distributed way (e. g. , Peer-to-Peer) on a Grid or on a Cloud infrastructure. The SON middleware allows to define new component types by specifying the services offered by each type. During execution it allows to dynamically combine different component instances and to manage the life cycle of these components (create, init, stop,.
Packaging OpenAlea into a virtual environment. OpenAlea and all its dependencies have been built and packaged into a virtual environment  [15]  on a virtual machine. The operating system (i. e. , a scientific Linux version 6) of the virtual machine is the same as the one deployed on each worker of the Grid. The virtual environment is packed and stored on iRODS. When a worker is reserved by DIRAC, the bundle is uploaded locally and uncompressed. A shell script updates the environment variables and an OpenAlea server is launched. This method has been preferred to virtualization (e. g. , vagrant or docker  [16] ) for performance reasons and because all the workers have the same operating system. The size of the compressed bundle containing all the packages and their dependencies is 210 MB. The latency (or delay) due to the copy of the bundle from iRODS and its installation is less than 1 min, while each worker is deployed once for a maximum of 24 hours.
Data management and Provenance Data management with iRODS. As previously stated, iRODS (v3. 3 ) is an open-source data system chosen by France-Grilles for its ability to provide a technology enabling data and policy virtualization for multiple and geographically separated users  [17]. iRODS federates distributed and heterogeneous data resources into a single logical file system and provides a modular interface to integrate new client-side applications. iRODS does not only allow the worker nodes of the grid infrastructure to access data sets but it provides end-users with access to data, through GUI, while enabling user to annotate such datasets with rich metadata. Both input data and the results of a scientific workflow computation associated with their provenance are stored on iRODS. This drastically reduces the volume of data to be transferred through SciFloware to launch a computation and retrieve its result (only the address of data in the central catalog has to be exchanged).
While iRODS is in charge of concretely managing data, the provenance module reconstructs (by querying iRODS) the history of each data item. In other words, the provenance module is able to provide for each produced data item the exact series of workflow node executions, including the data sets used as input of such nodes. Such provenance information is represented according to the W3C PROV standard  [19]. Both prospective (the workflow specification) and retrospective (execution and data sets) provenance are stored. Notebooks generator. The second component of the provenance layer aims at helping the PhenoArch users understand the results they obtained by allowing them to visualize and interact with the main steps of the process used to produce such results. In other words, we want PhenoArch users to be able to interact and visualize (part of) the execution of some workflows to follow how some final results have been obtained.
The current solution used by an increasing number of scientists to answer such kinds of need is to (manually) design notebooks using the Jupyter/IPython Notebook web application  [2]. From a developer point-of-view, a notebook is a JSON document (convertible into a number of open standard output formats including HTML, LaTeX, PDF. and which can be designed using a web-base user interface) containing an ordered list of input/output cells with iPython code able to generate text, mathematics, plots and rich media (images, video. ). From an end-user point-of-view, a notebook is a rich web page, where code, text, mathematics, plots and multimedia (images, video. ) can be displayed and interacted with. In particular any user can modify the input of a notebook cell to observe the impact of this change on the objects displayed (e.
g. , plots). In InfraPhenoGrid, we implement a notebook generator where a set of OpenAlea workflow executions are automatically converted into Jupyter/ IPython notebooks. More precisely, the generator (i) converts each Ope-nAlea workflow actor (natively coded in Python) into an IPython cell and (ii) queries iRODS to extract automatically information on input and output datasets respectively used and produced by the execution of each OpenAlea actor. Users can then visualize and interact with data used and produced during an execution. A concrete example of generated notebooks is provided in the next Section (Results).
For this project, France-Grilles provides us with 32 000 logical process units. With only a subset of this resource (2%), the whole computation, scheduled by SciFloware, can be performed in less than 12 hours (night time). Exploiting Provenance. During any execution, provenance data, that is, all the data items processed and produced (including intermediate and final images) are stored on iRODS. Based on this provenance information, IPython notebooks are automatically generated for each individual plant either at a given time, or for the entire growth period, or for a given genotype. Each cell of the notebook contains the script of the workflow node executed. The input/output data are direct references to the data produced and stored in iRODS. Very interestingly, users can upload a given notebook (see Figure  10 ) with the corresponding data, and modify the execution parameters directly on their computer to visualize the impact of such modifications and better understand their results.