dataesr/scientific-paragraphs-categorization huggingface dataset:
In addition, a non-parametric Wilcoxon signed rank test can be used to analyse whether the distribution of errors is significantly biased or not. These criteria can be seen as equivalent to common statistical criteria for quantitative models (Bias, Mean Absolute Error; Root Mean Square Error; Efficiency  [54] ). At last, methods specific to matched-pairs data with ordered categories can be used. In order to do so, various models comparing matched marginal distributions or analysing the joint distribution in a square contingency table can be applied  [55]. The qualitative attributes of IPSIM models can lead to threshold effects. In order to cope with this limitation, a tool, named proDEX was developed to model uncertain expert knowledge  [56]. This software offers the definition of probabilistic aggregating tables, where each combination of descendants' values maps to a probability distribution of the aggregated attributes, rather than a single value.
This study was carried out within a PhD project co-funded by  INRA  and  INPT EI Purpan , by the project  MICMAC design  ( ANR-09-STRA-06 ) supported by the  French National Agency for Research (ANR) , and by the  Programme ''Assessing  and reducing environmental risks from plant protection products (pesticides)'', funded by the  French Ministry in charge of Ecology and Sustainable Development  (project ''ASPIB''). The funders had no role in study design, data collection and analysis, decision to publish, or preparation of the manuscript.
When N becomes very large, it is no longer possible to store P m n (x j ) in memory (for N 1024 nowadays) and on-the-fly algorithms (which recompute P m n (x j ) from the recurrence relation when needed) are then the only possibility. We would like to stress that even far from that storage limit, on-the-fly algorithm can be significantly faster thanks to vector capabilities of modern processors. Most desktop and laptop computers, as well as many high performance computing clusters, have support for Single-Instruction-Multiple-Data (SIMD) operations in double precision. The SSE2 instruction set is available since year 2000 and currently supported by almost every PC, allowing to perform the same double precision arithmetic operations on a vector of 2 double precision numbers, effectively doubling the computing power.
Performance comparisons Table 1 reports the timing measurements of two SHT libraries, compared to the optimized Gauss-Legendre implementation found in the SHTns library (this work). We compare with the Gauss-Legendre implementation of libpsht  (Reinecke, 2011) , a parallel spherical harmonic transform library targeting very large N , and with SpharmonicKit 2. 7 (DH) which implements one of the Driscoll-Healy fast algorithms  (Healy et al. , 2003). All the timings are for a complete SHT, which includes the Fast Fourier Transform. Note that the Gauss-Legendre algorithm is by far (a factor of order 2) the fastest algorithm of the libpsht library. Note also that SpharmonicKit is limited to N + 1 being a power of two, requires 2(N + 1) latitudinal colocation points, and crashed for N = 2047. The software library implementing the fast Legendre transform described by  Mohlenkamp (1999) , libftsh, has also been tested, and found to be of comparable performance to that of SpharmonicKit, although the comparison is not straightforward because libftsh did not include the Fourier Transform.
Conclusion and perspectives Despite the many fast spherical harmonic transform algorithms published, the few with a publicly available implementation are far from the performance of a carefully written Gauss-Legendre algorithm, as implemented in the SHTns library, even for quite large truncation (N = 1023). Explicitly vectorized on-the-fly algorithms seem to be able to unleash the computing power of nowadays and future computers, without suffering too much of memory bandwidth limitations, which is an asset for multi-threaded transforms. The SHTns library has already been used in various demanding computations (eg. Schaeffer et al. , 2012; Augier and Lindborg, 2013; Figueroa et al. , 2013). The versatile truncation, the various normalization conventions supported, as well as the scalar and vector transform routines available for C/C++, Fortran or Python, should suit most of the current and future needs in high performance computing involving partial differential equations in spherical geometry.
We then fitted a type 1 (Gumbel) extreme value distribution on these data using a maximum likelihood estimate function in MATLAB. This allowed us to verify that the scores we obtained for the original sequence blocks were indeed significant and not solely a consequence of our optimization procedure. This procedure defined a multiple sequence alignment made of a number of blocks with locally optimized scores (called the seed alignment). Then two cases arose: 1. The 3D structure of a protein (the query) was not available but its sequence was sufficiently similar to the sequence of one of the proteins whose 3D structure had been solved (the target). We aligned the query sequence with the target sequence using a regular sequence alignment program. It was easy, then, to integrate, by transitivity, this query sequence into the seed alignment, since both alignments had the target sequence in common.
Phylogenetic analyses Since our proteins are highly divergent, we paid special attention to choosing an appropriate evolution model: we examined site-heterogeneous and branch heterogeneous models in addition to standard ones. This also explains why we considered only likelihood-based (maximum likelihood and Bayesian inference) reconstruction methods. We first used ProtTest  [24]  to determine the most appropriate evolution model among a set of standard candidates models. We used the Bayesian Information Criterion (BIC) to select the model. For all datasets, ProtTest selected LG + I + G or variations of it (LG is an evolutionary models for proteins developed by  [26] ). We then compared LG + I + G to various mixtures model tailored to the evolution of divergent proteins. Those models are CAT20, which assumes that each position belong to one of 20 categories, each characterized by a specific stationary amino-acid distribution and structure-based models that assigns positions to one of 2 to 6 categories, according to the secondary structure of the protein, and use a different substitution matrix for each category.
CAT20 and structure based models account for heterogeneity across sites in a much more specific way than standard rates across sites models. Multiple sequence alignments constructed as above were analyzed using both maximum likelihood (PhyML  [25]  for standard model and phyml-cat  [26]  and phymlstructure  [27]  for structure based models) and Bayesian inference (MrBayes  [28] ) methods. In ML analyses and to mitigate the effect of the starting tree, we used a full SPR search strategies with 5 random starting trees in addition to the default BIONJ starting trees. We included a proportion of invariable sites, optimized by the program (-v e), and a RAS modeled with a Gamma distribution with 4 categories with shape parameter optimized by the program (-c 4 -a e). For all alignments considered, at least 4 of the 5 random starting trees led to the same final tree as the BIONJ starting tree.
However, we found that this procedure clearly underestimated the significance thresholds. Therefore, to estimate empirically the significance of the peaks found in the KL divergence plot we carried out simulations using Seq-Gen  [30]. Seq-Gen is a program for simulating the evolution of nucleotide or protein sequences along a phylogeny, according to a particular model of substitution. We concatenated the multiple sequence alignments for the VP1, VP2, SPC, VP4 and VP3 birnavirus proteins of the eight taxa (SPC corresponds to the region between VP2 and VP4 that is part of the pro-VP2 polypeptide chain). Starting with each taxon concatenated amino acid sequence, in turn, we generated 13 multiple sequence alignments sets using the tree obtained for one of the above windows with MrBayes. This resulted in 104 sets of eight 897-amino acid long sequences.
No additional ORF was evidenced on this segment. The ORF in segment B consists of 3135 nt encoding a 1045 aa protein displaying 19-29% sequence identity with its birnavirus replicase homologs (Figures  2A  and B ). RBV thus appears as a new member of the Birnaviridae family that is divergent from other birnaviruses infecting vertebrates, mollusks or arthropods (GenBank accession numbers for segment A: FM995220, and segment B: FM995221).
Selection of an evolutionary model for virus protein evolution Since the phylogenetic analysis of virus proteins may be very difficult due to their fast and extensive divergence, using an appropriate model of amino acid replacement is critical to study RNA virus protein evolution and phylogeny. We used ProtTest  [24]  to select the best evolution model for our proteins. Among the models available in ProtTest, LG + G + I or variations of it (LG + I + G + F, LG + G) were selected for all datasets. It consists of the LG amino-acid substitution matrix supplemented with a fraction of invariable sites (+I) and rate heterogeneity across sites (RAS) model, modelled with a discrete Gamma distribution with four categories. In addition to this model, we explored various models specifically designed for divergent proteins.
Figures  6A  and B  presents, respectively, the maximum likelihood tree (PHYML) and the Bayesian consensus tree (MrBayes) for the 9 species. Both trees are congruent and show a fair support (bv = 0. 48 and pp = 0. 84) for the partition {Calici, Picorna | Flavi, Others}. The three alternative topologies T1 = {Calici, Flavi | Picorna, Others}, T2 = {Calici, Picorna | Flavi, Others} which is also the ML tree and T3 = {Calici, Others | Flavi, Picorna} have likelihood -3494. 03, -3491. 85 and -3495. 11. An AU test with these topologies almost rejects topology T3 (p = 0. 065) but cannot discard topology T1 (p = 0. 32). The bootstrap probabilities of these trees are 0. 29, 0. 69 and 0. 02 indicating a clear but not significant preference for topology T2 (see Additional file 3: Figure  S3 ). Additional file 4: Figure  S4  shows an evaluation, with the program TREE-PUZZLE  [38] , of the internal branch support of the three possible topologies that can be generated with these four groups using likelihood mapping for visualizing the phylogenetic content of the multiple sequence alignment.
D C Figure  6  Phylogenetic trees of RdRp proteins for +ssRNA and dsRNA viruses. Inset A: maximum likelihood (ML) tree for the nine RdRps whose 3D structure is known for the virus families considered in the study. Leaves are labeled with RdRp PDB codes (1urjA: Bacteriophage phi6; 2ppgA: Infectious bursal disease virus; 1 s48A: Bovine viral diarrhea virus; 2giqA: Hepatitis C virus NS5B; 1sh0A: Norwalk virus; 1khvA: Rabbit haemorrhagic disease virus; 2ec0A: Foot and mouth disease virus; 1xr7A: Human rhinovirus type 14; 2ijfA: Poliovirus. See Table  1  for more information). Viruses of the Picornaviridae family are displayed in green, those of the Caliciviridae family in orange, those of the Flaviviridae family in red and others (here dsRNA viruses of the Birnaviridae and Cystoviridae families) in blue; Inset B: Bayesian consensus tree for the same nine viruses; Inset C; ML tree for the previous nine viruses plus three viruses whose RdRp 3D structure is not available: Drosophila A virus (dav), N.
In the early nineties, Koonin and Dolja proposed hypothetical evolutionary scenarios for +ssRNA viruses based primarily on a tentative phylogeny of the RdRps and also on the gene order conservation in the different genomes  [46]. The phylogeny analysis was based on multiple sequence alignments of relatively short functional motifs and the generation of the trees was carried out with distance (UPGMA and least square methods, FITCH and KITSCH) and parsimony methods implemented in the Phylip package  [47]. A couple of years later, Zanotto et al. [48]  showed that the sequence similarities and B A Figure  7  Phylogenetic trees of capsid proteins for +ssRNA and dsRNA viruses. Inset A: ML tree for the seven capsid proteins whose 3D structure is available (1wcdJ: Infectious bursal disease virus; 1ohfA: N.
To increase the computation accuracy and to limit the computation time, the mesh is refined in the vicinity of the scratch. The contact and friction inequalities are solved using the penalty method  [33]. For very low levels of scratching conditions (small penetration compared to tip radius, low friction coefficient), numerical simulations can be performed without remeshing algorithm. Let us note that an automatic remeshing procedure was implemented in the finite element software Systus to study more severe scratching conditions  [3]. Similarly to the experimental study, the tip radius is  = 35 m, the temperature is  = 25 ∘ C, the tip velocities are  = 0. 1 m⋅s -1 ,  = 1 m⋅s -1 , and  = 10 m⋅s -1 , and the normal load is constant and identical to the experimental one (  = 20 mN,   = 40 mN and   = 80 mN).
However, the numerical loading is achieved by controlling the quasistatic displacement of the indenter. A specific algorithm has thus been developed in the finite element software (Systus) to ensure the control of the load. It adjusts the vertical displacement to maintain the normal load constant, at each time step. Let us note that the adhesion friction coefficient (Coulomb) is adapted at each velocity and each normal load to exactly reproduce the friction coefficient measured during the experimental microscratches ( measured =  adhesion +  ploughing  [2, 34] ).
Viscoelastic-Viscoplastic Model with the "Series Model". To account for both viscoelasticity and viscoplasticity, we have developed a specific algorithm  [22] , named "series model" in the finite element code Systus. It makes it possible to connect series two models of any kind (Figure  12 ). Such algorithm is helpful to combine very quickly whatever models, if their constitutive equations are available in the finite element code in the same framework (updated lagrangian, total lagrangian, etc. ). The algorithm uses an iterative process which calculates the dispatching of the strain rate to ensure the equality of the stress tensors. This algorithm can be summarized as in Figure  13. Our case study needs to connect a viscoelastic model with a viscoplastic one. Young modulus chosen in the previous section can be considered as the instantaneous and delayed modulus of the viscoelastic model (Figure  14 ).
The CUPIB mode is not tied to an application and NL protocol event, but rather is a mode that executes the adaptation solution at a certain period of time. A detail description of these adaptation modes can be consulted in section III-C. As shown in Fig. 2 , we modeled an adaptation solution as a module containing an algorithm, which receives as input a list of context elements values, and produces as output a list of values used to execute adaption actions which are parametrized with these values. Before executing an adaptation solution the architecture will retrieve the current context element values from a context environment defined in the architecture. This context environment is made by different context sources offering context elements; more Fig. 2. PLUGAM architecture graphical representation details on these context sources and the definition of a context element can be found in section III-B.
The architecture defines four context sources: An NL protocol, an application and finally entities that offer local-node context elements (e. g. information from a GPS or an automobile sensor), each context source could offer multiple context elements. Each context element has meta-information associated to it like a name, the data type of the context element, etc. At run-time, at a given time t, a context element CE has a value CE(t), which can be retrieved by querying its context source. At run-time a context element value is encapsulated by the ContextElementValue class, which contains a name field to store the name of the context element, the value field to store the current value of the context element (to be able to store any data type in java an Object class is used), and a type field to store the data type of the context value (in java a Class class is used).
A context manager module in the middleware handles the retrieval of the current context element value from the source via either the polling or publish and subscribe methods, concurrently to the execution of the adaptation solutions. The PLUGAM architecture is flexible by allowing the context sources to offer the current values only by the polling method, and implement the publish and subscribe method optionally; the context manager favors using the publish and subscribe method if available. The context manager stores the current values of the context elements in an internal direct access memory structure (e. g. hash tables). The idea is to always have an up-to-date context environment, thus at the time when an adaptation solution is executing and it needs the latest values of the context elements, the context manager simply gets these values directly from the context manager direct access structure, instead of going to the context source to get the current value.
This adaptation action can only be used in the send, receive and forward adaptation modes. The filter receives as input a boolean data type where a value of true means that the filter lets the message pass to the destination protocol or application, with a value of false the message is dropped. In Fig. 9 b ) shows an example of how the filter works, in this example the adaptation solution having the filter receives the value of false, the filter then drops the message and it does not go to the NL protocol #1. To finalize the description of the adaptation actions, the architecture introduces the AdaptationActionValue class to represent the value of an adaptation action at run-time similar to the context element value concept. An adaptation action value can also be of any data type similar to a context element value, which is why the definition of the Adaptation-ActionValue class contains exactly the same attributes as the ContextElementValue class.
g. in  [11]  the mobility metric is based on link duration of the neighbor nodes), nonetheless to simplify the description of this case study example we think that using the vehicle speed serves the purpose. We proposed to obtain the vehicle speed by creating a ContextE plug-in wrapping a GPS code which calculates this information by measuring the Doppler shift in the signals from the GPS satellites, this ContextE plug-in will offer the middleware the context element of "vehicle speed". In addition, we need to describe the adaptation algorithm that we will use for the case study 1 adaptation solution. We decided to create an extremely simple adaptation algorithm based on one-on-one mapping between the vehicle speed and the HELLO INTERVAL value. The adopted vehicle speed and HELLO INTERVAL relationship is based on the following simple reasoning: at higher vehicle speed the neighbors change more rapidly, hence the neighbor table must be updated more often by lowering the value of the HELLO INTERVAL.
V. DESCRIPTION OF PROOF OF CONCEPT PROTOTYPE As proof of concept we decided to implement a prototype of the PLUGAM adaptation middleware. An important aspect for the prototype was to find a proper plug-in platform. In addition, working on an implementation of the PLUGAM architecture helped us better define some lower level details of the architecture and have a more solid proposal. In this section we present the implementation details of this prototype. In regard to the search for a plug-in platform, we found some plug-in frameworks, platforms in Java and C#, and HTML programming languages. For example the Chrome extension framework  11  allows the creation of extensions (plug-ins) developed in HTML and packed inside a zip file containing the HTML code and a manifest in JSON format to store the extension's meta-data.
The main reason to select OSGi as the plug-in platform is because the OSGi is a solid platform; also its community is currently very active, there is a lot of development to improve and extend the platform and there are a lot of additional tools to deal with bundles. The other technology constituting the plug-in platform is iPOJO 13 , its purpose is to simplify OSGi application development and promotes service-oriented programming on OSGi platforms. Based on the concept of POJO (Plain Old Java Object), application logic is developed easily. A PLUGAM plug-in will be implemented as an iPOJO service. Thanks to iPOJO there is no need to make reference or calls to OSGi code to be able to implement an application module via OSGi, the linking of OSGi and the iPOJO component service to the application logic is made at the compilation level.
In addition to developing the plug-in platform of the prototype, we implemented some test plug-ins. Specifically we implemented the necessary plug-ins 13 iPOJO webpage: http://felix. apache. org/site/apache-felix-ipojo. html 14 Apache Felix webpage: http://felix. apache. org/site/index. html 15 Apache ServiceMix is an open source Enterprise Service Bus: http://servicemix. apache. org/home. html to implement the case study 1 example in the prototype: • A OLSR protocol plug-in which is developed using the OLSR code found inside the Mchannel 16  middleware implementation. This plug-in offers an adaptation action to modify the HELLO INTERVAL of OLSR. • A contextE plug-in offering GPS context information by connecting to a Bluetooth GPS; we modified the base code of the GPSylon project  17  to create the plug-in.
• Finally we are interested in analyzing the memory and processing overhead introduced by the prototype's plugin platform. All the measurements performed to the prototype where made on a MacBook Air model A1231 (2008), which contains an Intel Core Duo 1. 6GHz and 2Gb of RAM. On the software side, we used the Ubuntu 10. 10 operating system, the installed software is Java JRE 1. 6. 0. 22, Apache Felix version 4. 0. 2 and iPOJO 1. 8. 2. We believe that these hardware and software specifications will be similar to the on-board systems of two-three years future vehicles, with a price point of $700-1100 USD, using computer tecnology from four or five years behind and most probably using a version of Linux or Windows Embedded. For example the MyFord Touch costs around $1150 USD an uses Microsofts Windows Embedded Auto software platform, has an ARM Cortex A8 600 MHz CPU with 512 MB RAM, 2 GB NAND flash memory.
In regard to the iPOJO code overhead, we found that it adds an average of 3. 5 KB of code to the plug-in binary. Moreover it increases the size of the class file implementing the iPOJO service by 86. 84%, this code overhead originates because adding iPOJO functionality involves an injection of iPOJO specific methods to the original CLASS file; this code injection is done automatically by the Apache Ant compiler. As we mentioned in previous sections, the plug-in platform communicates the extension components (added NL protocols, applications, etc. ) to the middleware, this communication using the plug-in platform adds a processing overhead or extra latency that we think is interesting to measure. To calculate this latency we recreated a scenario in which we have two iPOJO components A and B, where A uses the B component and both components are located in different bundles or JAR files.