dataesr/scientific-paragraphs-categorization huggingface dataset:
Signal to noise ratios Characterising the noise in a MUSE datacube is not trivial, as each voxel of the cube is interpolated not only spatially, but also in the spectral domain, and each may inherit flux from just one up to ∼30 original CCD pixels. While readout and photon noise are formally propagated by the MUSE pipeline as pixel variances, correlations between two neighbouring spatial pixels cause these predicted variances to be systematically too low. Furthermore, the degree of correlation between two neighbouring spatial pixels varies substantially across the field (and with wavelength), on spatial scales comparable or larger than real astronomical objects in a deep field such as the HDFS. A correct error propagation also accounting for the covariances between pixels is theoretically possible, but given the size of a MUSE dataset this is unfortunately prohibitive with current computing  resources.
One such tool is based on SExtractor  (Bertin &Arnouts 1996)  which was run on narrow-band images produced by averaging each wavelength plane of the cube with the 4 closest wavelength planes, adopting a weighting scheme which follows the profile on an emission line with a velocity σ = 100 km/s. This procedure was performed accross the full wavelength range of the cube to enhance the detection of single emission lines (see also  Richard et al. 2014). All SExtractor catalogs obtained from each narrow-band image were merged and compared with the continuum estimation from the white light image to select emission lines. A different approach was used in the LSDCat software (Herenz, in prep. ), which was specifically designed to search for line emitters not associated with continuum sources in the MUSE data cube.
This is, however, only the first step. Further improvements of the data reduction process -such as super flat-fields or optimal combination of exposures -are still possible and will be implemented in the near future. We are also developing new methods for 3D source detections, optimized for the large size of the MUSE data cubes  (Paris et al. 2013, Herenz in prep. , Meillier in prep, Cantalupo in prep). With these new tools and an improved data reduction, we expect to further extend the number of secure redshift identifications in the field. This will be the subject of a future public release for the HDFS field. Another major milestone is expected in a few years, when the Adaptive Optics Facility will come in operations at UT4  (Arsenault et al. 2012). The four laser guide stars, the deformable VLT secondary mirror and GALACSI, the module dedicated to MUSE  (Ströbele et al.
Acknowledgements. We thanks  Laure Piqueras  and  Gerard Zins  for their support with analysis and observation software. We also warmly thank  Fernando Selman  and all Paranal staff for their enthusiastic support of  MUSE  during the commissioning runs. RB acknowledges support from the  ERC  advanced grant MUSICOS. JR, BC, VP acknowledges support from the  ERC  starting grant CALENDS. TC, BG, AD acknowledges support from the  ANR FOGHAR. LM acknowledges support from the  Lyon Institute of Origins  under grant  ANR-10-LABX-66. SJL and KS acknowledge support from the  Swiss National Science Foundation.
Haptic Authoring Tools Unison is an extensible framework to standardize the development process of hapto-visual applications. With this framework, a user is required to develop a plug-in to install a component into the framework  (El-Far et al. , 2004). The Haptik Library is a software library which enables to provide uniform access to haptic devices  (Pascale and Prattichizzo, 2007). The library does not support higher capabilities to simulate haptic rendering such as collision detection so that significant programming effort is required. Cha et al. (Cha et al. , 2007)  proposes an authoring tool that enables to haptically enhance broadcast contents as well as to provide viewers via streaming in a VOD context. This framework supports an only passive haptic interaction for a user. HAMLAT is an authoring tool for haptic application development  (Eid et al.
Component-based Haptic Authoring Tool To date, we have developed a component-based 486 Yamaguchi T. , Oshima K. , Hirano Y. , Makishima A. , Harada T. and Richard P. haptic authoring framework for Unity3D  (Yamaguchi et al. , 2014). This framework was designed as an extensible module using a component capability extension mechanisms supported by Unity3D (Unity Technologies, 2005) to accommodate the range of predictable variation that will be needed in different specific purpose of haptic interaction. Unity3D is one of the most well designed component-based game development platform that enables rapid prototyping of high quality 2D/3D game. It runs on multiplatform such as Mac OS X, Windows, Linux, android, and even a web browser. The proposed haptic component in the previous study  (Yamaguchi et al.
Haptic Device Controller Module The "Haptic Device Controller" works as an interface to the connected haptic device and retrieves its status as well as dispatches the status to the other components including the "Haptic Model" module. The haptic device status includes a grip position of the haptic device, a button status, and so on. These statuses are updated at 60Hz. A core thread of this module is implemented as a C++ based Dynamic Link Library (DLL) to access the API of the haptic device, as well as to manage a haptic rendering process at 1 kHz.
Haptic Model Module The "Haptic Model" module enables to manage reaction force calculation logic, a database of the haptic device status. The reaction force calculation process is running at 1 kHz to calculate a reaction force for an applied haptic component. The calculated force is sent to the "Haptic Device Controller" module to display it via the connected haptic device. This module is listed on the Built-in components in Unity3D. We categorized a common haptic interaction in navigation into two abstract components such as "Move", and "Caution". These abstract components are defined as sub modules of the "Haptic Model" module. Each haptic component is associated with a visual object which represents a visually defined work area related to a haptic effect of the linked haptic component.
The area of forest plantations is increasing worldwide helping to meet timber demand and protect natural forests. However, with global change, monospecific plantations are increasingly vulnerable to abiotic and biotic disturbances. As an adaption measure we need to move to plantations that are more diverse in genotypes, species, and structure, with a design underpinned by science. TreeDivNet, a global network of tree diversity experiments, responds to this need by assessing the advantages and disadvantages of mixed species plantations. The network currently consists of 18 experiments, distributed over 36 sites and five ecoregions. With plantations 1-15 years old, TreeDivNet can already provide relevant data for forest policy and management. In this paper, we highlight some early results on the carbon sequestration and pest resistance potential of more diverse plantations.
According to FAO's Global Planted Forest Assessment database  (FAO 2006) , the total number of species used in plantations ranges from four in Finland to twenty in China, France, India, and Ukraine. Yet, studies in TreeDivNet experimental plantations suggest that the carbon sequestration rates of tree species that are rarely planted in forestry may be higher than for species that are traditionally planted for wood production. In Sardinilla, Panama, for instance, only one of the four species with the highest carbon stocks after 10 years of growth, Dalbergia retusa, is currently used as a timber-producing species (Fig. 3a ). In BEF-China, Choerospondias axillaris, Nyssa sinensis, Triadica cochinchinensis, Melia azedarach, and Schima superba, which are not currently used for commercial timber, were found to sequester more carbon 2 years after planting than the commercially planted timber species Cunninghamia lanceolata or Pinus massioniana.
ID TreeDivNet experiments also allow comparing the provisioning of ecosystem services from mixed as opposed to monoculture plantations. A recent meta-analysis, using data from a TreeDivNet experiment and elsewhere, indicates that woody mixtures sequester at least as much aboveground carbon as the most productive monocultures in any given location  (Hulvey et al. 2013). This suggests that plantations could use mixtures of multiple species selected outside of traditional forestry practice to maximize aboveground carbon storage, if the latter would be the primary interest. Furthermore, early TreeDivNet results indicate that the performance of high carbon sequestering species might be contingent upon the diversity level of the plot in which they are growing. In BangorDIVERSE, UK, Alnus glutinosa and Betula pendula were more efficient at storing carbon after 9 years than some traditional timberproducing species, with A.
Interestingly, there were more cases found for associational susceptibility, which might be due to the young age of the experiments and/or the assessment of all insect damage rather than focus on few pests, as done in other studies. Insect damage is now a staple protocol in most TreeDivNet experiments and so more results over a greater span of conditions will be available soon. A recent meta-analysis, which included data from several TreeDivNet experiments, has shown that both phylogenetic relatedness of tree species in mixtures and insect herbivore feeding specialization are important predictors of forest diversity effects on insect pests  (Castagneyrol et al. 2014). The degree of dilution of a focal tree species among non-host trees was also important in associational resistance  (Castagneyrol et al.
Software Product Line Engineering (SPLE) is a software engineering paradigm that focuses on reuse and variability. Although feature-oriented programming (FOP) can implement software product line efficiently, we still need a method to generate and prove correctness of all product variants more efficiently and automatically. In this context, we propose to manipulate feature modules which contain three kinds of artifacts: specification, code and correctness proof. We depict a methodology and a platform that help the user to automatically produce correct-by-construction product variants from the related feature modules. As a first step of this project, we begin by proposing a language, GFML, allowing the developer to write such feature modules. This language is designed so that the artifacts can be easily reused and composed.
Introduction Software Product Line Engineering (SPLE) is a paradigm used to develop software-intensive systems that share common assets  [14, 1]. In SPLE, a feature is used to represent a characteristic behavior as a unit of functionality of the software product line (SPL)  [1]. Given a set of features, the configuration of a SPL is constructed by composing the features. Following generative programming mechanisms  [4] , the respective product variant can be derived automatically from a feature selection and artifacts of each selected feature. The product generation may be realized through Feature-Oriented Programming (FOP) techniques  [7] , in which each feature is mapped to a feature module containing its artifacts. The product variant is synthesized from the artifacts of the involved feature modules.
In this context, we demonstrate our approach that helps the developer to write feature modules containing their artifacts using a dedicated and generic language. Some authors proposed approaches for constructing product variants of a product line by reusing and synthesizing artifacts. Using design by contract  [13]  and adhering to FOP techniques, Thüm proposed a proof composition approach and strategies to reduce the effort of verification by reusing partial proofs  [18]  [17]  [16]. The FEATUREHOUSE framework, described in  [2] , enables the construction of a new program from existing programs using the structure of the SPL feature tree. Although the above methods can implement software product line efficiently and mostly automatically, we still need a method to generate and prove correctness of all product variants more efficiently and automatically.
In this direction some advances have been proposed in the context of programming language metatheory within the Coq proof assistant  [10]   [11]. However these tools are dedicated to a very specific domain and still require an important expertise. To tackle the above limitations, we depict a methodology that helps the user to automatically produce correct-by-construction product variants. This methodology aims at being independent of any concrete target language but at first we focus and experiment with FoCaLiZe, a language used to specify, implement and prove (http://focalize. inria. fr). In this paper, we propose a language, called GFML (for Generic Feature Module Language) allowing the developer to write feature modules which contain three kinds of artifacts: specifications, code and correctness proofs.
GFML is inspired from FoCaLiZe but sticks to a FOP approach and tries to reduce the developer's effort. This language is designed so that the artifacts can be easily reused, composed and translated into different languages. In Section 2, we first describe the background of our paper, in particular we present briefly FoCaL-iZe. Then in Section 3, we illustrate our definition of feature module and a brief description of our language (GFML) used to write feature modules. In Section 4, we illustrate the translation of GFML into FoCaLiZe. In Section 5, we describe how to compose two feature modules by giving an example, and depict a composition framework for automatically generating correct-by-construction product variants. In Section 6, we review related work. Finally we conclude the paper and discuss future works in Section 7.
Software Product Line In SPLE, a feature is a characteristic behavior specified as a unit of functionality of a product line  [1]. A set of features, called a feature model, is often graphically depicted as a tree, also called a feature diagram. In addition to the presentation of commonality and variability, a feature diagram also contains various relationships and additional constraints between features. The main relationships in feature diagrams are optional/mandatory, alternative/or and implies/excludes. Because of visual aid, feature diagrams are considered as standard representations that help the user to choose product configurations of a product line. In this work, we only focus on a simple form of feature diagrams (i. e. Figure  1 ) that can illustrate optional features. In our work, we only consider valid configurations.
Quick Presentation of FoCaLiZe This subsection presents briefly the technical background necessary to understand the section about the translation of GFML to FoCaLiZe. The FoCaLiZe (http://focalize. inria. fr) environment provides a set of tools to describe and implement functions and logical statements together with their proof. A FoCaLiZe source program is analyzed and translated into OCaml sources for execution and Coq sources for certification. The FoCaLiZe language has an object oriented flavor allowing inheritance, late binding and redefinition. These characteristics are very helpful to reuse specifications, implementations and proofs. A FoCaLiZe specification can be seen as a set of algebraic properties describing relations between input and output of the functions implemented in a FoCaLiZe program.
For writing code, FoCaLiZe offers a pure functional programming style close to ML, featuring strong typing, recursive functions, data types and pattern-matching. Proofs written using the FoCaLiZe proof language are sent to the Zenon prover which produces proofs that can be verified by Coq for more confidence  [9]. The FoCaLiZe proof language is a declarative language in which the programmer states a property and gives hints to achieve its proof which is performed by Zenon. FoCaLiZe units are called collections. They contain entities in a model akin to classes and objects or types and values. Collections have functions and properties which can be called using the "!" notation. They are derived from other units called species which specify and implement functions. A species defines a set of entities together with functions and properties applying to them.
Description of GFML We propose a generic language, called GFML, to write these feature modules. Each feature module is embedded into a separate file. gfm. This language is suitable for all feature modules possibly containing three kinds of artifacts: specifications, code and correctness proofs. This language is inspired from FoCaLiZe, in particular the styles for writing specifications, code and proofs are common. GFML and FoCaLiZe mainly differ in the way to structure and organize information. Our main objective in defining GFML is to propose a language close to FoCaLiZe that already allows for the three kinds of artifacts in a single setting but closer to the description of commonality and variability we can find in feature diagrams. As we will see in Section 4, the expression of a feature module is much simpler that its translation in FoCaLiZe.
The new conclusion states that this operation has to modify the account by updating the amount of withdrawn money. The representation type of module DL is defined as a Cartesian product of int (i. e. the concrete type associated with the amount of money withdrawn in a day) and the representation type of the parent (line 11). The functions withdraw and update are defined/redefined (lines 12-23). We can notice that in the redefinition of update the call to the parent function update is done with the parameter x, there is here an implicit conversion that will be inserted during the translation into FoCaLiZe. The proof of the property update succ DL reuses the property update succ BA as a proof hint (line 26). All modifications and additions compared to the parent module BA are highlighted or underlined.
From GFML to FoCaLiZe In this section, we illustrate the translation from GFML to FoCaLiZe. A GFML feature module is mapped into three FoCaLiZe separate species. The first species Inh contains all desired elements that are inherited in the child module. These elements can be function declarations, properties or predicates. A predicate, which is introduced with the keyword 'logical let' and named l cons, is associated with each property p found in a module. For example, the feature module BA written in Figure  4a  is mapped to the species Inh BA (line 1). A predicate l cons update succ BA (line 5) is associated with the property update succ BA. In Figure  4b , the species Inh DL of the child DL inherits the species Inh BA of module BA (line 2). The FoCaLiZe inheritance mechanism allows the programmer to reuse the artifacts without any change (except for functions that can be redefined without changing its signature).
But although some properties may be kept in the child module, others may be modified by adding new premises or/and new conclusions. In this last case, the FoCaLiZe inheritance mechanism is not sufficient. We have to use the parametrization facility to encode the right meaning. To tackle this limitation, we propose the second species Reu that inherits the first species Inh. It includes all desired specifications that are reused to describe new ones in the child. Each property specified in this species must have a corresponding predicate l cons in the first species Inh. Instead of mentioning the property, we use this predicate for expressing new properties in the child. This trick is used because FoCaLiZe does not allow the modification of an inherited property in a species. For example, in Figure  4a  species Reu BA inherits  The parametrization mechanism in FoCaLize is used here to circumvent the fact that in FoCaLiZe when the representation type is fixed in a species P, it cannot be changed in any species which inherits P.
In the proof of the refining property update succ DL, property update succ BA of the parent BA is considered as a proof hint (line 30). Its associated formula l cons update succ BA is also a proof hint (line 29). Let us notice that Zenon, the FoCaLiZe prover has done all the proofs with the given hints. We can notice that the use of a language such as FoCaLiZe for implementing and verifying feature modules is quite complex. The proposed language GFML is a solution to write the feature modules together with their artifacts more easily. We have followed with success this translation scheme for all the features appearing on the feature diagram of Figure  2. For the moment, the translation is done manually.
Conclusion In this paper we have described a first step towards the production of a methodology allowing for the development of correct-by-construction product variants according to a FOP paradigm. The contribution is here the definition of the language GFML allowing the developer to write feature modules containing their specifications, code and correctness proofs. These modules are translated to FoCaLiZe for verification and also for obtaining OCaml operational code. Consequently the product variants we are aiming at will be implemented in OCaml. GFML is here introduced to help the developer when he is writing the different feature modules, allowing him to describe the artifacts of a feature with respect to the artifacts of its parents. Realizing this directly in FoCaLiZe is a difficult task as it is exemplified by the translation scheme presented in a previous section.
Non-invasive local deformation measurements. We first processed the SHG images to measure the local deformation tensor and verified whether it was equal to the global stretch ratio applied to the tissue. This issue was mandatory to compare the local data with the macroscopic ones since the skin tissue may exhibit an inhomogeneous response or slip slightly within the jaws. We therefore used the hair follicles as endogenous tags and measured the deformation of their network before and after stretching (see Material and Methods and Supplementary Fig. S3 ). To that end, appropriate image processing was developed to identify and label the same hair follicles in a region of interest (ROI) common to all images and to calculate the three independent components of the local deformation tensor using Delaunay triangulation (see Fig.
Mechanical assays without multiphoton imaging. See Supplementary Material. Mechanical data processing. The motor displacement and resulting force were measured continuously during the whole experiments (Fig. 1c ). The global stretch ratio was obtained as: λ = ( ) l l 1 0 where l is the length between the jaws and l 0 the reference length. Note that because of the uncertainty in the reference length, the absolute stretch is not precisely defined; nevertheless, the differences in stretch ratio are accurately determined. The nominal stress was obtained as the measured force divided by the initial skin section (w 0 × e 0 ). Also because of the uncertainty in the skin section measurements, the absolute stress is not precisely measured, while the variations of stress are accurately determined. To quantify the mechanical properties of the sample, we used four parameters (Fig.