dataesr/scientific-paragraphs-categorization huggingface dataset:
02 units (1/ 0. 98). Incorrect decisions were valued to be worth 0 units of profit. For this type of profit matrix, the average Profit Score would be 2. 0 if all damaged and undamaged stands were correctly predicted by the logistic regression model. This is in contrast to an estimated average Profit Score of just 1. 0 if SCs were selected at random and predicted to be either damaged or undamaged. (ii) The data were partitioned into a training (60%) and a validation (40%) dataset. This random allocation of data records was stratified by the target variable 'damage' to ensure that records with damage and no damage were allocated in the same proportions to both the training and validation datasets. (iii) A stepwise logistic regression analysis was done. The selected model was chosen from the step that produced the largest total Profit Score for the validation dataset.
Acknowledgments This research was funded by  Corporate and Forestry Support, Forestry Commission ,  Great Britain  and an  INRA   Scientific Package  awarded to the second author. We are grateful to the Cowal and Trossachs Forest District of  Forestry Commission, Scotland  for their cooperation and assistance with this study, and in particular we would like to thank  John Hair  for his unfailing helpfulness and patience concerning all our demands for data and information. We would also like to acknowledge  NASA  for provision of the ASTER DTM data. ASTER GDEM is a product of  METI  and  NASA. Our thanks are also due to the three anonymous referees and the editor whose comments and suggestions have greatly improved this manuscript and our evaluation of model performance.
Apparatus Subjects sat in a dimly lit room, 57 cm away from a 17-inch (30 • × 40 • of visual angle) computer screen (140 Hz) with their head stabilized by a chin rest, cheekbone rests, and forehead support. Visual stimuli (0. 6 • diameter black dots on a grey background) were presented using a Visual Stimuli Generation system (Cambridge Research Systems, Cambridge, UK). Binocular eye movements were recorded at a frequency of 500 Hz and spatial resolution of 0. 05 • using an infrared tracker (EyeLink 1000, SR Research, Canada). A calibration of the Eye tracker was performed before each recording session by asking subjects to serially fixate nine dots constituting a rectangle (28 • × 38 • ) covering the computer screen surface. Laboratorydeveloped software coupled with a real-time interface allowed on-line monitoring of eye movements and triggering of the visual stimulation.
Data Analysis Eye movement data were analyzed off-line using custom software developed in Matlab v. 7. 1 (Math Works Inc. , Natick, MA, USA). Data from the left and right eyes were averaged. The start and end positions of each primary horizontal saccade were identified based on a velocity threshold of 50 • /s, and were used to compute saccadic amplitude and gain. Saccadic amplitude was the difference between the initial and the final positions of the eye. Saccadic gain was calculated by dividing saccade amplitude by target retinal eccentricity (difference between the target position and the starting position of the saccade). The mean saccadic gain was obtained separately for each group, for rightward and leftward saccades and for pre-and post-exposure phases. Then, the gain change between pre-and post-exposure was calculated separately for the adapted and non-adapted hemifields, and for the reactive and voluntary saccades.
Acknowledgments This work was funded by  FRM , the  James S. McDonnell Foundation , and the  LABEX CORTEX  (Grant  ANR-11-LABX-0042 ) of  University of Lyon , within the  Investments in the Future Programme  (Grant  ANR-11-IDEX-0007 ) operated by the  French National Research Agency. We thank all subjects for their participation in this study. We also thank  M. Panouillères  and  A. Khan  for helpful comments.
0. 1  [18]. To our knowledge, this project constitutes the best analyzable form of the UML specification openly available; it has been constructed according to the UML 2. 2 specification. • MOF (Meta-Object Facility) version 2. 0  [4]. The specification that created the standard for the exchange of metadata, therefore creating the language for metamodels themselves. It was created from the modeling foundations of UML and comprises two metamodels, Essential MOF (EMOF) and Complete MOF (CMOF). • OCL version 2. 2  [5]. We analyze the specification of the OCL language itself, which contains four metamodels. An Ecore implementation of the four metamodels is available from the Eclipse OCL project  [19]. We consider only the two metamodels that contain OCL invariants, namely OCL types and OCL expressions.
It has been developed with USE at University of Bremen. • HRC (Heterogeneous Rich Components) is a metamodel created within the european research project SPEEDS with the Kermeta metamodeling environment  [24]. Industrial community: This group contains metamodels developed in enterprises using model-driven techniques for their software projects. • MTEP and XMS are metamodels created by Thomson Video Networks for encoding standards for video hardware. • SAM is a metamodel from the Topcased open source software project. Table  1  details a list of standard specifications of modeling languages coming from different sources. Each specification contains one or more metamodels. The first two columns contain the name and group; The third column counts the number of metamodels. In the OMG group, specifications define large modeling languages, normally structured in packages, therefore we treat each one of these as a separate metamodel.
The metric values are finally analyzed with R 5 (activity Statistical Analysis in figure  8 ). R is an open-source language for statistical applications, which provides several functionalities to run analysis and create plots, both one-variable and multi-variable. For metamodel analysis, we provide a set of generic scripts that could be used for any CSV file produced with OCLMetrics. These scripts automate the production of graphics (statistical charts in figure  8  in terms of bar plots, boxplots and treemaps) to help the metrics analysis over the metamodel.
MetricsAnalysis relies on the binding between MOF/Ecore and OCL as shown in figure  7  to load and manipulate the corresponding models. The tool uses the Ecore and OCL metamodels defined in the packages Ecore and OCL. The class MetricsAnalysis mainly defines data sets (reference datasets) and metrics (reference metrics) specified in the previous section. Each data set (class DatasetDefinition) is implemented in the method query() that computes the resulting collection for a given metamodel. A data set is used by a metric (class MetricDefinition) whose definition is implemented in the method compute(). This component also creates the following. csv files of data: • TabAllInvariants: Table measuring the metrics at the invariant level; each record corresponds to an invariant, described by an identifier given by the metamodel where it is defined, followed by the context class and then an unique ID number.
This is followed by all the metrics at the invariant level. • TabAllClasses: Table measuring the metrics at the class level; each record corresponds to a class in a metamodel, described by an identifier given by the metamodel where it is defined and then an unique ID number. This is followed by all the metrics at the class level, which summarize all the invariants that have been defined with this class as context. • TabAllMetamodels: Table measuring the metrics at the metamodel level; each record corresponds to a metamodel, describing all the metrics at the metamodel level, which summarize all the invariants that have been defined within this metamodel. As a whole, OCLMetrics consists of 11 classes, with a total of 486 lines of Java code. It can be extended with new data sets and metric definitions by implementing new subclasses to the classes DatasetDefinition and Met-ricDefinition respectively.
Construction threats lie in the way we define our metrics and their measurement. The way we have defined metrics to answer our research questions responds to our own judgement on how to measure this phenomena. How-ever, another choice of metrics and statistical descriptive analysis may yield different results and consequently produce different conclusions. Validity of our results could also be affected by analysis and calculations performed by our program OCL Metrics. Although the algorithms were designed to follow precisely the metric definitions presented in section 3, and integrally analyzed the abstract syntax tree of each invariant, subtleties and assumptions made by the underlying tools (particularly Eclipse OCL) are the subject of possible bias. Our metrics result might be too coarse grained to draw pertinent conclusions, and other metrics might be better fitted for this purpose.
Package def : packageContent ( ) : C o l l e c t i o n <C l a s s > = s e l f. ownedType->s e l e c t ( t | t. oclIsTypeOf ( C l a s s ) ) Listing 1: 'Definition of the packageContent dataset' context Package def : p a c k a g e A l l C o n t e n t ( ) : C o l l e c t i o n <C l a s s > = s e l f. ownedType->s e l e c t ( t | t. oclIsTypeOf ( C l a s s ) ). union ( s e l f. nestedPakages ->c o l l e c t ( p | p. p a c k a g e A l l C o n t e n t ( ) ) ) Listing 2: 'Definition of the packageAllContent dataset' context C l a s s def : c l a s s C o n t e n t ( ) : C o l l e c t i o n <Property> = s e l f. ownedAttribute Listing 3: 'Definition of the classContent dataset'.
Acknowledgements The authors wish to thank  Jens Brüning ,  Bastien Coatanéa-Gouachet ,  Pierre Gaufillet ,  Prof. Martin Gogolla ,  Akram Idani ,  Mirco Kuhlmann ,  Holger Schmidt , for their valuable contribution to our study with data subjects. We also thank  James Hill ,  Bran Selic ,  Juha-Pekka Tolvanen  and  Fabian Buttner  for their support about this study. Special thanks to  Véronique Thelen , associate professor in the  Economy department of University of Lille 1 , for her helpful advice on our quantitative analysis.
context Package def : packageContent ( ) : C o l l e c t i o n <C l a s s > = s e l f. ownedType->s e l e c t ( t | t. oclIsTypeOf ( C l a s s ) ) Listing 1: 'Definition of the packageContent dataset' context Package def : p a c k a g e A l l C o n t e n t ( ) : C o l l e c t i o n <C l a s s > = s e l f. ownedType->s e l e c t ( t | t. oclIsTypeOf ( C l a s s ) ). union ( s e l f. nestedPakages ->c o l l e c t ( p | p. p a c k a g e A l l C o n t e n t ( ) ) ) Listing 2: 'Definition of the packageAllContent dataset' context C l a s s def : c l a s s C o n t e n t ( ) : C o l l e c t i o n <Property> = s e l f. ownedAttribute Listing 3: 'Definition of the classContent dataset'.
Geant4 VMC History VMC defines an abstract layer between a detector simulation user code and the Monte Carlo transport code (MC). In this way the user code is independent from any specific MC and can be used with different transport codes, such as GEANT 3. 21  [9] , Geant4  [4]  or FLUKA  [10] , within the same simulation application. It was developed by the ALICE Offline Project and, after the complete removal of all dependencies from the experiment specific framework, it was included in ROOT. The first version of the VMC interface was included in ROOT 3. 03/05 in October 2002. The Geant4 VMC version series started with version 0. 1 and continued up to version 0. 5. The base Geant4 and ROOT versions for this release, as well as for the next Geant4 VMC major releases, are presented in Table  1  The major version 1.
0 included geometry convertors which allowed to use geometry defined with new ROOT geometrical modeller, TGeo  [11] , in a VMC application. This 1. 0 version was released in July 2003. The geometry convertors were gradually replaced with usage of an external tool, VGM  [12]  and removed from Geant4 VMC in version 1. 8. The 1. x series continued up to version 1. 9 for three years. The next major version, 2. 0, released in December 2006, included the G4Root package which implements Geant4 navigation that uses directly the TGeo geometry. G4Root was moved in Geant4 VMC from ROOT in order to group together Geant4 related packages based on ROOT and to facilitate their building for the user. In this version, the geometry definition in all examples was reimplemented with usage of TGeo geometry modeller.
These functions are then used to clone the application and its containing objects on thread workers. Creating these objects on worker threads is then triggered from the Geant4 VMC classes. Detailed instructions for migration of VMC applications to multithreading are provided on the VMC Web site together with other implementation details and useful tips. // required A new set of classes taking care of locking critical ROOT operations in multithreading mode -as for example registering ROOT objects to ROOT trees -is introduced in a new MTRoot package. This package enhanced the ROOT input/output functionality previously provided by the Ex02RootManager class within the examples. MTRoot is independent from the Geant4 VMC interface, but it is used in VMC examples. It provides TMCRootManager and TMCRootManagerMT, the ROOT manager classes for VMC sequential and multithreaded applications respectively.
Both these classes are derived from a common interface and are introduced in terms of a single implementation class in order to avoid code duplication, see Figure  1. In addition, a utility class TMCAutoLock, providing a locking mechanism, is also included in this package. It was extracted from the G4AutoLock class implementation in Geant4 for Linux and MAC OSX platforms. The G4Root package is the interface allowing running a Geant4 simulation with a ROOT geometry. In spite of being provided within Geant4 VMC, it can be built and used independently.
While the VMC application libraries are independent from specific Monte Carlo libraries, the VMC application program has to be linked also with selected Monte Carlo libraries including their VMC interface. That is why two sets of "Find" and "Use" files were defined: FindVMC, UseVMC and FindMC, UseMC. The former are used for building the VMC application library and the latter for the program. "Find" files are used to find all needed packages and "Use" files to set compiler definitions, includes and libraries according to selected configuration options. Besides being provided in Geant4 VMC, they are also available in Geant3 +VMC. interpreter incompatibility was a separation of macros for loading libraries from the single macros used to run VMC example. Minor fixes were also needed in the code to make it compiling against C++11 standard, mandatory with this ROOT version.
Testing VMC testing is based on shell scripts which run automatically 21 test configurations plus a special test for all Geant4 available physics lists, the list of which is updated after each Geant4 release. The test configurations are continuously enhanced while adding new features in Geant4 VMC. In addition to the existing test suite run from the standard ROOT session, in version 3. 0 we added a second test suite which runs the same tests configurations from examples programs. The test suites perform tests with both GEANT3 and Geant4 simulation programs. The test scripts were also improved to facilitate their possible inclusion in automated testing. Command line arguments were added to make possible to select testing with one simulation program only, either GEANT3 or Geant4, or to change the test build directory.
A navigation system (OrthoPilot, Aesculap, Tuttlingen, FRG) was used as a gold standard. Ten patients, operated for end-stage osteoarthritis by navigation assisted for total knee arthroplasty, participated to the study. The knee was passively positioned at four full extensions and at maximal flexion angle. For each set of measurements, six navigated and six Smartphone data sets were obtained. Statistical analyses were performed with paired Student's -test, and Spearman's coefficient of correlation, Bland and Altman plots, and intraand interobserver reproducibility were assessed using ICC. Validity results were as follows: LOA was equal to 27. 4 ∘ , -test was not significant, Spearman's coefficient of correlation is 0. 99, and B&A had good coherence. Intra-and interobserver ICC were, respectively, 0.
3. 2 The SimpopLocal model is a multi-agent model developed with the Scala software programming language. The landscape of the simulation space is composed of a hundred of settlements. Each settlement is considered as a fixed agent and is described by three attributes: The location of its permanent habitat, the size of its population, and the available resources in its local environment. The amount of available resources is quantified in units of inhabitants and can be understood as the carrying capacity of the local environment for sustaining a population. This carrying capacity depends on the resources exploitation skills that the local population has acquired from inventing or acquiring innovation. Each new innovation acquired by a settlement develops its exploitation skills. This resource exploitation is done locally and sharing or trade is not explicitly represented in the model.
3. 18 This section exposes results of the CP algorithm on each of the six free parameters of SimpopLocal. Each profile presented in this paper has required the achievement of 100,000 CPU hours time (meaning that it would have required 100,000 hours of computation on a single core of a modern processor). To achieve such a huge computational load we have distributed it across the numerous CPU of the European computation grid EGI (European Grid Infrastructure) using the distributed implementation of CP that we have integrated into OpenMOLE. The effective user time was around 15 days to compute all the profiles achieving a gain of 2200. The OpenMOLE script files used to compute those profiles have been made available [5].
Acknowledgements This work is funded by the  ERC Advanced Grant Geodivercity  and the  Institut des Systèmes Complexes Paris Île-de-France. The results obtained in this paper were computed on the biomed and the vo. complex-system. euvirtual organization of the  European Grid Infrastructure  (http://www. egi. eu). We thank the  European Grid Infrastructure  and its supporting  National Grid Initiatives (France-Grilles in particular)  for providing the technical support and infrastructure. We also thank the  Réseau National des Systèmes Complexes (RNSC)  and anonymous reviewers for their help in improving the first version of the paper.
Architecture This section describes the authoring pipeline proposed in this paper. The description gives details of all the stages composing the pipeline, the software therein used, and how the stages are connect with each other. Four stages compose the authoring pipeline, as depicted in Figure  3 : 1) Creation of the 3D character, 2) Animation of the character's face using a Natural User Interface, 3) Refinement of the animation using traditional mouse+keyboard approach, and 4) Exportation of the resulting animation as movie or as animation data. Stage 1 of the proposed pipeline is based on MakeHuman  5  : an open-source tool for making 3D characters  [15]. MakeHuman allows non-expert users for easily authoring a digital character in all its details, without the need to accomplish the complex actions required by full-fledged 3D animation tool (like Autodesk's 3D Studio and Maya, or the opensource Blender), such as vertex-based modelling, vertex weighting, UV mapping, and control rig construction.
The 3D mesh includes a rich set of blend shapes for facial animation (70 in total). Finally, the character offers both a facial Stage 2 of the pipeline consists of animating the character via a performance capture, within the Blender software, using a Natural User Interface. The performance capture is based on the use of a depth sensor (like the Microsoft Kinect, or any equivalent on the market) together with the FaceShift 6  application. FaceShift is an application able to use a 3D depth sensor to reconstruct the 3D mesh of a face an animate it in real-time according to the actual facial expression of the performer. The details of its underlying implementation can be seen in  [8]. Faceshift is based on the OpenNI 7  middleware, which guarantees compatibility with a wide range of Kinect-like hardware available on the consumer market.
FaceShift requires a calibration phase for each user. The calibration, lasting less than 10 minutes, consists of mimicking a set of facial expressions. While keeping an expression on his/her face, the user turns his/her head of about 30 degrees on both sides, for a couple of times, to let the system collect data about the shape of the face. The result of the calibration is a 3D reconstruction of the user head and face. The 3D face can be animated via blendshape deformations. FaceShift can be used in real-time tracking mode. Here, the user face expression framed by the Kinect is continuously analyzed and used to pilot the 3D reconstruction of the user face. The integration with Blender is performed thanks to the capability of FaceShift to output its tracking information to TCP or UDP network sockets.
The captured data, which include the vector with the blendshape weights, is processed by a Blender addon, written in Python, developed by the authors. The Blender addon, described in Section 4, decodes the FaceShift binary network communication protocol and allows for the real-time recording of the facial expression and the head movement. More importantly, the addon maps the FaceShift blend shapes values to the control rig of the face. In so doing, the Blender user can have access to the control rig animation keyframes to further edit the facial animation. Stage 3 of the pipeline allows for the user to manually operate on the control rig to refine facial animations. Obviously, the refinement of the facial and head animations can be associated to a synchronised full body animation for a more comprehensive production.
The recording session generates animation keyframes at a rate of about 30 frames per seconds. As a result, animations present a very high data density which makes them hardly editable by hand. Thus, in our pipeline we suggest to perform a curve simplification through the simplify curve addon included by default in Blender. Finally, in Stage 4, the edited animations can be rendered as videos, or image sequences, or stored in a separate Gesticon (gestures and animations repository). A Gesticon is intended to be a repository of classified animation data that can be reused across different scenes of the same project or across different projects. Common actions such as smiling, walking, running, or a full set of signs used in sign languages are all perfect candidates for a Gesticon. The pipeline was developed and tested with the following software versions: MakeHuman v1.
Real-time Mapping of Tracked Blendshapes to Control-rig This section describes the retargeting method which converts the tracking information received by FaceShift into the MakeHuman control rig. The method has been developed as an addon of the Blender 3D authoring tool and is implemented in the Python language. The tracking information sent by FaceShift are received by the addon via UDP packets. The addon uses the following data: The mapping script works as follows. If the track_ok flag is false, the received data are skipped and the MakeHuman rig isn't moved. Otherwise. The rotation of the head rotation is directly applied to controller Neck. The theta and pi rotation angles of the eyes are mapped as -theta, 0, phi euler angles (in XY Z order) to the controllers Eye_L and Eye_R. Finally, the blend shape values are mapped to offsets of the facial control rig, as described in the rest of this section.