dataesr/scientific-paragraphs-categorization huggingface dataset:
EGN analytical workflow EGN is a script implemented in Perl. v5. 10. 1 on the Linux and MacOSX platforms for generating evolutionary gene and genome networks from molecular data (proteic and/or nucleic sequences). A simple menu allows users to easily manage the step by step procedure and set up relevant parameters for their analyses. However, BLASTall (v ≥ 2. 2. 26)  [30]  or BLAT  [35]  must be installed on the computer where EGN is executed, and their directory locations properly specified in the OS. Once EGN is installed, it will take as input one or many files of sequences (in FASTA format) located in a working directory, chosen by the user (e. g. /myEGNanalysis/). The extension of these files must be either. fna, for DNA and RNA sequences, or. faa, for protein sequences. In the case of unique sequence type, user can choose between BLAST or BLAT homology searches to compare these sequences.
If the dataset is composed of both nucleic and proteic sequences, BLAST will be chosen and EGN will automatically run BLASTN for nucleic sequences comparison, BLASTP for proteic sequences comparison, while comparisons between nucleic and proteic sequences will be performed by BLASTX and TBLASTN. To this end, EGN must simply be invoked using the command line 'perl egn. pl'. The software then proposes several analyses, organized in a stepwise fashion (Figure  1 ). First, EGN parses the FASTA infiles present in the working directory to i) check that their format is correct (i. e. all sequences have a unique identifier, etc. ), ii) to extract useful information about the sequences that will figure in the nodes of the networks under reconstruction (e. g. the sequences/samples/organisms names…), and iii) to assign a local EGN identifier to each sequence in order to speed up the next calculation steps.
Once this step of creation of properly formatted input files (option 1, in EGN Main Menu) is successfully achieved, the user can perform two kinds of similarity searches between sequences in these files (option 2 in EGN Main Menu), either by selecting BLASTall  [30] , or BLAT  [31] , a faster software program, that speeds up the analysis of very large sequence infiles, but may be less accurate. The user can edit the egn. config file to modify the search parameters of each of these programs or use the wizard implemented in EGN. On multi-core computers, the speed of the BLAST search can be enhanced by changing the number of processors (parameter -a, set to 2 by default). Likewise, we implemented the parallelization of multiple BLAT processes in EGN (default value = 2 in egn. config). In order to reconstruct a comprehensive similarity network, all sequences can be compared against all.
Application to real data We used EGN to illustrate how its various options areuseful for devising and testing evolutionary hypotheses, while taking into account a large amount of data structured according to this data type. We tested whether plasmids were always used as genetic couriers, moving DNA from one lineage to another in a dataset of 571,044 protein sequences (see Implementation). We first used EGN (e-value ≤ 1E-20, hit identity ≥ 30% ) to reconstruct a genome network of 131 cellular organisms, 2,211 plasmids and 3,477 viral genomes, harboring either cellular chromosomes or genomes of mobile genetic elements at its nodes, connected when they shared sequences from the same similarity cluster, as in Halary et al. [25]. In the genome network, some plasmids displayed markedly distinct behaviors and patterns of connections, identifying two extreme sorts of plasmids.
Genomic datasets and analysis parameters We sampled 571,044 protein sequences from the chromosomes of 70 eubacterial complete genomes, 54 archaebacterial complete genomes, and 7 eukaryotic genomes, covering the diversity of cellular life, as well as from the genomes of two types of mobile genetic elements: 228,040 protein sequences from all the available plasmids and phages at the time of this analysis from the NCBI (see Additional files). We first used EGN (e-value cutoff 1E-05, identity thresholds 30%) to construct a genome network, harboring either cellular chromosomes or genomes of mobile genetic elements at its nodes, connected when they shared sequences belonging to the same cluster of similar sequences, as in Halary et al. [25]. To test whether plasmids hosted in a bacterial lineage were connected to genomes in multiple other lineages, we estimated the conductance of their nodes (C) in the genome network.
Availability and requirements Project name:EGN Project home page: http://www. evol-net. fr/index. php/fr/downloads Operating system(s): Linux Platform and OSX Programming language: Perl. v5. 10. 1 Other requirements: BLAST + versions ≥ v2. 2. 25 or BLAST all versions ≥ v2. 2. 26 or BLAT License: GNU GPL Any restrictions to use by non-academics: none.
Models for the latest stages of the cosmological evolution rely on a less solid theoretical and observational ground than the description of earlier stages like BBN and recombination. As suggested in a previous work by Vonlanthen et al. , it is possible to tweak the analysis of CMB data in such way to avoid making assumptions on the late evolution, and obtain robust constraints on "early cosmology parameters". We extend this method in order to marginalise the results over CMB lensing contamination, and present updated results based on recent CMB data. Our constraints on the minimal early cosmology model are weaker than in a standard ΛCDM analysis, but do not conflict with this model. Besides, we obtain conservative bounds on the effective neutrino number and neutrino mass, showing no hints for extra relativistic degrees of freedom, and proving in a robust way that neutrinos experienced their non-relativistic transition after the time of photon decoupling.
In this work, we carry a similar analysis, pushed to a higher precision level since we also avoid making assumptions on the contamination of primary CMB anisotropies by weak lensing. We use the most recent available data from the Wilkinson Microwave Anisotropy Probe (WMAP) and South Pole Telescope (SPT) data, and consider the case of a minimal "early cosmology" model, as well as extended models with free density of ultra-relativistic relics or massive neutrinos. This analysis is an occasion to present a new cosmological parameter inference code. This Monte Carlo code written in Python, called Monte Python 1 , offers a convenient alternative to CosmoMC  [4]. It is interfaced with the Boltzmann code class 2   [2, 3]. Monte Python is released publicly together with this work. In section 2, we explain the method allowing to get constraints only on the early cosmological evolution.
We present our result for the minimal early cosmology model in section 3, and for two extended models in section 4. In section 5, we briefly summarize some of the advantages of Monte Pyhton, without entering into technical details (presented anyway in the code documentation). Our conclusions are highlighted in section 6. 2 How to test early cosmology only? The spectrum of primary CMB temperature anisotropies is sensitive to various physical effects: • (C1) the location of the acoustic peaks in multipole space depends on the sound horizon at decoupling d s (τ rec ) (an "early cosmology"-dependent parameter) divided by the angular diameter distance to decoupling d A (τ rec ) (a "late cosmology"-dependent parameter, sensitive to the recent background evolution: acceleration, spatial curvature, etc.
(3. 1) Hence, the choice (A lp , n lp )=(1,0) corresponds to the standard lensing potential predicted in the ΛCDM model. Different values correspond to an arbitrary rescaling or tilting of the lensing potential, which can be propagated consistently to the lensed CMB temperature/polarization spectrum. The sixth run shown in Table  1  corresponds to n lp = 0 and a free parameter A lp. The minimum credible interval for this rescaling parameter is A lp = 0. 88 +0. 12 -0. 13 at the 68% Confidence Level (CL), and is compatible with one. This shows that WMAP7+SPT data alone are sensitive to lensing, and well compatible with the lensing signal predicted by the minimal ΛCDM model. It is also interesting to note that the bounds on other cosmological parameter move a little bit, but only by a small amount (compared to the difference between the ΛCDM and the previous "agnostic" runs), showing that "agnostic bounds" are robust.
Published bounds on M ν from CMB data alone probe all these intricate effects  [5] , and it would be instructive to obtain robust bounds based only on the mass impact on "early cosmology". For the effective neutrino number, we performed two runs similar to our previous ΛCDM and "fully agnostic" run (with marginalization over lensing amplitude and tilt), in presence of one additional free parameter N eff. Our results are summarized in Table  2  and Figure  3. In the ΛCDM+N eff case, we get N eff = 3. 77 +0. 58 -0. 66 (68% CL), very close to the result of  [11] , N eff = 3. 85 ± 0. 62 (differences in the priors can explain this insignificant difference). It is well-known by now that the combination of WMAP and small-scale CMB data shows a marginal preference for extra relativistic degrees of freedom in the seven-parameter model.
Advantages of Monte Python The results of this paper were obtained with the new parameter inference code Monte Python, that we release publicly together with this article. Currently, Monte Python is interfaced with the Boltzmann code class, and explores parameter space with the Metropolis-Hastings algorithm, just like CosmoMC 3  (note however that interfacing it with other codes and switching to other exploration algorithms would be easy, thanks to the modular architecture of the code). Hence, the difference with CosmoMC  [4]  does not reside in a radically different strategy, but in several details aiming at making the user's life easy. It is not our goal to describe here all the features implemented in Monte Python: for that, we refer the reader to the documentation distributed with the code.
We only present here a brief summary of the main specificities of Monte Python. Language and compilation. As suggested by its name, Monte Python is a Monte Carlo code written in Python. This high-level language allows to code with a very concise style: Monte Python is compact, and the implementation of e. g. new likelihoods requires very few lines. Python is also ideal for wrapping other codes from different languages: Monte Python needs to call class, written in C, and the WMAP likelihood code, written in Fortran 90. The user not familiar with Python should not worry: for most purposes, Monte Python does not need to be edited, when CosmoMC would need to: this is explained in the fourth paragraph below. Another advantage of Python is that it includes many libraries (and an easy way to add more), so that Monte Python is self-contained.
Modularity. A parameter inference code is based on distinct blocks: a likelihood exploration algorithm, an interface with a code computing theoretical predictions (in our case, a Boltzmann code solving the cosmological background and perturbation evolution), and an interface with each experimental likelihood. In Monte Python, all three blocks are clearly split in distinct modules. This would make it easy, e. g. , to interface Monte Python with camb  [12]  instead of class, or to switch from the in-build Metropolis-Hastings algorithm to another method, e. g. a nested sampling algorithm. The design choice of the code has been to write these modules as different classes, in the sense of C++, whenever it served a purpose. For instance, all likelihoods are defined as separated classes. It allows for easy and intuitive way of comparing two runs, and helps simplify the code.
The cosmological module is also defined as a class, with a defined amount of functions. If someone writes a python wrapper for camb defining these same functions, then Monte Python would be ready to serve. On the other hand the likelihood exploration part is contained in a normal file, defining only functions. The actual computation is only done in the file code/mcmc. py, so it is easy to implement a different exploration algorithm. From the rest of the code, this step would be as transparent as possible. In Python, like in C++, a class can inherit properties from a parent class. This becomes particularly powerful when dealing with data likelihoods. Each likelihood will inherit from a basic likelihood class, able to read data files, and to treat storage. In order to implement a new likelihood, one then only needs to write the computation part, leaving the rest automatically done by the main code.
This avoids several repetitions of the same piece of code. Furthermore, if the likelihood falls in a generic category, like CMB likelihoods based on reading a file in the format. newdat (same files as in CosmoMC), it will inherit more precise properties from the likelihood_newdat class, which is itself a daughter of the likelihood class. Hence, in order to incorporate CMB likelihoods apart from WMAP, one only needs to write one line of python for each new case: it is enough to tell, e. g. , to the class accounting for the CMB experiment SPT that it inherits all properties from the generic likelihood_newdat class. Then, this class is ready to read a file in the. newdat format and to work. Note that our code already incorporates another generic likelihood class that will be useful in the future for reading Planck likelihoods, after the release of Planck data.
param file, the chain will start (it will not take the same name as previous chains: it will append automatically to its name a number equal to the first available number in the chain directory). In addition, the user who wishes to launch new chains for the same run can omit to pass an input file: in this case all the information about the run is automatically read in the log. param and the chain can start. The existence of log. param file has another advantage. When one wants to analyze chains and produce result files and plots (the equivalent of running Getdist and matlab or maple in the case of CosmoMC), one simply needs to tell Monte Python to analyze a given directory. It is not needed to pass another input file, since all information on parameter names and ranges will be found in the log.
param. If the output needs to be customized (i. e. , changing the name of the parameters, plotting only a few of them, rescaling them by some factor, etc. ), then the user can use command lines and eventually pass one small input file with extra information. No need to edit the code when adding parameters. The name of cosmological parameters is never defined in Monte Python. The code only knows that in the input file, it will read a list of parameter names (e. g. omega_b, z_reio, etc. ) and pass this list to the cosmology code together with some values. The cosmology code (in our case, class) will read these names and values as if they were written in an input file. If one of the names is not understood by the cosmology code, the run stops. The advantage is that the user can immediately write in the input file any name understood by class, without needing to edit Monte Python.
This is not the case with CosmoMC. This is why users can do lots of things with Monte Python without ever needing to edit it or even knowing Python. If one wants to explore a completely new cosmological model, it is enough to check that it is implemented in class (or to implement it oneself and recompile the class python wrapper). But Monte Python doesn't need to know about the change. To be precise, in the Monte Python input file, the user is expected to pass the name, value, prior edge etc. of all parameters (i) to be varied; (ii) to be fixed; (iii) to be stored in the chains as derived parameters. These can be any class parameter: cosmological parameters, precision parameters, flags, input file names. Let us take two examples: • In this paper, we showed some posterior probabilities for the angular diameter distance up to recombination.
It turns out that this parameter is always computed and stored by class, under the name 'da_rec'. Hence we only needed to write in the input file of Monte Python a line looking roughly like da_rec='derived' (see the documentation for the exact syntax), and this parameter was stored in the chains. In this case Monte Python did not need editing. The user is also free to rescale a parameter (e. g. A s to 10 9 A s in order to avoid dealing with exponents everywhere) by specifying a rescaling factor in the input file of Monte Python: so this can be done without editing neither Monte Python nor class. Please note however that, while this is true that any input parameter will be understood directly by the code, to recover derived parameters, the wrapper routine (distributed with class) should know about them.
Friendly plotting. The chains produced by Monte Python are exactly in the same format as those produced by CosmoMC: the user is free to analyze them with GetDist or with a customized code. However Monte Python incorporates its own analysis module, that produce output files and one or two dimensional plots in PDF format (including the usual "triangle plot"). Thanks to the existence of log. param files, we just need to tell Monte Python to analyze a given directory -no other input is needed. Information on the parameter best-fit, mean, minimal credible intervals, convergence, etc. , are then written in three output files with different presentation: a text file with horizontal ordering of the parameters, a text file with vertical ordering, and a latex file producing a latex table. In the plots, the code will convert parameter names to latex format automatically (at least in the simplest case) in order to write nice labels (e.
g. it has a routine that will automatically replace tau_reio by \tau_{reio}). If the output needs to be customized (i. e. , changing the name of the parameters, plotting only a few of them, rescaling them by some factor, etc. ), then the user can use command lines and eventually pass one small input file with extra information. The code stores in the directory of the run only a few PDF files (by default, only two; more if the user asks for individual parameter plots), instead of lots of data files that would be needed if we were relying on an external plotting software like Matlab. Convenient use of mock data. The released version of Monte Python includes simplified likelihood codes mimicking the sensitivity of Planck, of a Euclid-like galaxy redshift survey, and of a Euclid-like cosmic shear survey.
The users can take inspiration from these modules to build other mock data likelihoods. They have been developed in such way that dealing with mock data is easy and fully automatized. The first time that a run is launched, Monte Python will find that the mock data file does not exist, and will create one using the fiducial model parameters passed in input. In the next runs, the power spectra of the fiducial model will be used as an ordinary data set. This approach is similar to the one developed in the code FuturCMB 5   [13]  compatible with CosmoMC, except that the same steps needed to be performed manually.
We extended the analysis to two non-minimal models changing the "early cosmology", with either a free density of ultra-relativistic relics, or some massive neutrinos that could become non-relativistic before or around photon decoupling. In the case of free N eff , it is striking that the "agnostic" analysis removes any hint in favor of extra relics. The allowed range is compatible with the standard value N eff = 3. 046 roughly at the one-sigma level, with a mean smaller than three. In the case with free total neutrino mass M ν , it is remarkable that the "agnostic" analysis remains sensitive to this mass: the two-sigma bound coincides almost exactly with the value of individual masses corresponding to a non-relativistic transition taking place at the time of photon decoupling. The derivation of these robust bounds was also for us an occasion to describe the main feature of the new parameter inference code Monte Python, that we release together with this paper.
More formally, the monotone classification problem (see, e. g. ,  [25] ) consists in finding an order preserving extension λ defined on the description space X generated by the X j 's, of a monotone consistent labelling function λ specified on a set of object descriptions E ⊆ X. Anyway, real data are generally neither monotone consistent nor consistent, i. e. , λ could not be monotone on E or worse λ could be only a relation on E × C. In the literature, some monotone classifiers have been proposed  [2, 3, 7, 6, 18, 11, 27]  but, as shown in  [4] , they deeply suffer from non-monotone noise present in the data and in many cases do not have classification accuracy as primary goal. Moreover, in order to ensure the monotonicity of the final classifier λ , a monotonization phase of the initial dataset or of the final classifier could be necessary  [10, 25] , causing a possible loss of information.
In particular, the global monotonicity constraint acts on the final classifier λ and so it requires an a priori knowledge of the entire tree. Hence, global monotonicity is difficult to enforce in an inductive construction procedure since at each step only one attribute can be taken into account. Our aim is to inductively build a decision tree exploiting somehow the eventual monotonicity present in the dataset, anyway, since no assumption of 8th Conference of the European Society for Fuzzy Logic and Technology (EUSFLAT 2013) © 2013. The authors -Published by Atlantis Press monotonicity is made on the data, we need to relax requirements on the final dataset. This is why, in our approach, we adopt a greedy strategy: at each step of the building process we choose the attribute a j "enforcing the most" the local monotonicity constraint, i.
e. , for all ω i , ω h ∈ Ω, a j (ω i ) ≤ a j (ω h ) ⇒ λ(ω i ) ≤ λ(ω h ). As a consequence it is not possible to expect a globally monotone classifier in the end. Nevertheless, we seek at least a weak form of monotonicity in the case the given dataset is monotone consistent. In order to build a monotone decision tree, new kinds of discrimination measures should be used. More precisely, measures able to quantify the monotonicity of λ w. r. t. a j and being robust to nonmonotone noise are required in such a process. In  [15]  the authors propose a rank generalization of Shannon mutual information, namely rank mutual information, which is a combination of Shannon entropy with dominance rough set relation  [12, 13] , based on the object-wise writing of Shannon entropy. In the same paper they underline that this measure is both sensitive to monotonicity and robust to noisy data.
In  [14]  this measure is used to build binary tree classifiers guaranteed to possess a weak form of monotonicity (rule monotonicity) in the case the starting dataset is monotone consistent. They call this TDIDT algorithm REMT and show it behaves well compared to both monotone and nonmonotone classifiers. Moreover, in  [16]  they use the rank mutual information for feature selection. In  [23] , we applied the same rank generalization procedure given in  [15]  to other two deeply studied discrimination measures such as Gini measure and Yuan and Shaw measure, moreover we introduced directly a third measure not having a non-monotone counterpart. A detailed study of aforementioned measures has been carried on in  [22]. In order to show the effectiveness of the proposed measures we wrote a binary tree classifier parametrized by a rank discrimination measure H *.