dataesr/scientific-paragraphs-categorization huggingface dataset:
Overview of the Research Topic We will now briefly summarize the 24 articles in the Research Topic, drawing out common themes. Both  Southey et al. (2008)  and  Yanashima et al. (2009)  use Python for bioinformatics applications, but in very different areas. Yanashima et al. have developed a Python package for graph-theoretical analysis of biomolecular networks, BioNetpy, and employed it to investigate protein networks associated with Alzheimer's disease. Southey et al. 's study demonstrates the wide breadth of application of Python, and the large number of high quality scientific libraries available, combining existing tools for bioinformatics, machine learning and web development to build an integrated pipeline for identification of prohormone precursors and prediction of prohormone cleavage sites.
Jurica and van Leeuwen (2009)  address the needs of scientists who already have significant amounts of code written in MATLAB R and who wish to transfer this to Python. They present OMPC, which uses syntax adaptation and emulation to allow transparent import of existing MATLAB R functions into Python programs. Three articles reported on new tools in the domain of neuroimaging. Hanke et al. (2009)  report on PyMVPA, a Python framework for machine learning-based data analysis, and its application to analysis of fMRI, EEG, MEG, and extracellular electrophysiology recordings. Gouws et al. (2009)  describe DataViewer3D, a Python application for displaying and integrating data from multiple neuroimaging modalities, showcasing Python's abilities to easily interface with libraries written in other languages, such as C++, and to integrate them into user-friendly systems.
Strangman et al. (2009)  emphasize the advantages of Python for "swift prototyping followed by efficient transition to stable production systems" in their description of NinPy, a toolkit for near-infrared neuroimaging. Zito et al. (2009)  and  Ince et al. (2009)  both report on the use of Python for general purpose data analysis, with a focus on machine learning and information theory respectively. Zito et al. have developed MDP, the Modular toolkit for Data Processing, a collection of computationally efficient data analysis modules that can be combined into complex pipelines. MDP was originally developed for theoretical research in neuroscience, but has broad application in general scientific data analysis and in teaching. Ince et al. (2009)  describe the use of Python for information-theoretic analysis of neuroscience data, outlining algorithmic, statistical and numerical challenges in the application of information theory in neuroscience, and explaining how the use of Python has significantly improved the speed and domain of applicability of the algorithms, allowing more ambitious analyses of more complex data sets.
Their code is available as an open-source package, pyEntropy. Three articles report on tools for visual stimulus generation, for use in visual neurophysiology and psychophysics experiments. Straw (2008)  describes VisionEgg, while  Peirce (2009)  presents PsychoPy, both of which are easy-to-use and easy-to-install applications that make use of OpenGL to generate temporally and spatially precise, arbitrarily complex visual stimulation protocols. Python is used to provide a simple, intuitive interface to the underlying graphics libraries, to provide a graphical user interface, and to interface with external hardware. PsychoPy can also generate and deliver auditory stimuli. Spacek et al. (2009)  also report on a Python library for visual stimulus generation, as part of a toolkit for the acquisition and analysis of highly parallel electrophysiological recordings from cat and rat visual cortex.
The other two components in the toolkit are for electrophysiological waveform visualization and spike sorting; and for spike train and stimulus analysis. The authors note "The requirements and solutions for these projects differed greatly, yet we found Python to be well suited for all three. " Also in the domain of electrophysiology,  Garcia and Fourcaud-Trocmé (2009)  describe OpenElectrophy, an application for efficient storage and analysis of large electrophysiology datasets, which includes a graphical user interface for interactive visualization and exploration and a library of analysis routines, including several spike-sorting methods. By far the largest contribution to the Research Topic came from the field of modeling and simulation, with 12 articles on the topic. Nine of these articles present neuroscience simulation environments with Python scripting interfaces.
In most cases, the Python interface was added to an existing simulator written in a compiled language such as C++. This was the case for NEU-RON  (Hines et al. , 2009) , NEST  (Eppler et al. , 2009) , PCSIM  (Pecevski et al. , 2009) , Nengo  (Stewart et al. , 2009) , MOOSE  (Ray and Bhalla, 2008) , STEPS  (Wils and De Schutter, 2009)  and NCS  (Drewes et al. , 2009). However, as the articles by  Goodman and Brette (2008)  on the Brian simulator and  Bednar (2009)  on the Topographica simulator demonstrate, it is also possible to develop new simulation environments purely in Python, making use of the vectorization techniques available in the underlying NumPy package to obtain computational efficiency. The range of modeling domains of these simulators is wide, from stochastic simulation of coupled reaction-diffusion systems (STEPS), through simulation of morphologically detailed neurons and networks (NEURON, MOOSE), highly-efficient large-scale networks of spiking point neurons (NEST, PCSIM, NCS, Brian) to population coding or point-neuron models of large brain regions (Nengo, Topographica).
Note that although we have categorized each simulator by its main area of application, most of these tools support modeling at a range of scales and levels of detail:  Bednar (2009) , for example, describes the integration of a spiking NEST simulation as one component in a Topographica simulation. The addition of Python interfaces to such a large number of widely used simulation environments suggested a huge opportunity to enhance interoperability between different simulators, making use of the common scripting language, which in turn has the potential to enhance the transfer of technology, knowledge and models between users of the different simulators, and to promote model reuse. Davison et al. (2009a)  describe PyNN, a common Python interface to multiple simulators, which enables the same modeling and simulation script to be run on any supported simulator without modification.
At the time of writing, PyNN supports NEURON, NEST, PCSIM and Brian, with MOOSE support under development. The existence of such a common "metasimulator" then makes it much easier for scientists developing new, hardware-based approaches to neural simulation to engage with the computational neuroscience community, as evidenced by the article by  Brüderle et al. (2009)  on interfacing a novel neuromorphic hardware system with PyNN. Finally,  Fox et al. (2009)  describe the possibilities when one is not limited to a single simulator, but can use Python to integrate multiple models into a brain-wide system. In their development of an integrated basal ganglia-hippocampal formation model for spatial navigation and its embodiment in a simulated robotic environment, Fox et al. found that Python offers "a significant reduction in development time, without a corresponding significant increase in execution time.
Discussion This editorial is being written 6 years after the first articles in the Research Topic were published. It is with the benefit of considerable hindsight, therefore, that we can confidently say that our goals in launching this Research Topic-to establish a critical mass for Python use and development in the eyes of the community and to encourage interoperability and collaboration between developers-have been met or exceeded. The average number of citations per article for the Research Topic as a whole is 54, or approximately 9 per year, using figures from Google Scholar. Although citation counts from Google Scholar tend to be higher than those from Journal Citation Reports so the numbers are not directly comparable, this compares favorably with the impact factors of well respected journals such as Journal of Neuroscience or PLoS Computational Biology.
Some of the articles were much more highly cited, with three of them being cited more than 20 times per year, on average, over the period. Four of the articles were chosen to "climb the tier" in the Frontiers system, and were followed up by Focused Review articles in Frontiers in Neuroscience  (Davison et al. , 2009b; Goodman and Brette, 2009; Hanke et al. , 2010; Ince et al. , 2010) , another was the subject of a commentary  (Einevoll, 2009). Concerning the goals of interoperability and collaboration, several articles in a follow-up volume Python in Neuroscience II attest to the degree to which the developers of different tools have worked together, and prioritized interoperability in recent years. For example, the developers of OpenElectrophy  (Garcia and Fourcaud-Trocmé, 2009)  and the community around PyNN  (Davison et al.
, 2009a)  formed the nucleus of an effort to develop a baseline Python representation for electrophysiology data, which resulted in the Neo project, reported in the Python in Neuroscience II Research Topic  (Garcia et al. , 2014)  together with two of the several projects which build on Neo  (Pröpper and Obermayer, 2013; Sobolev et al. , 2014). A new workflow system for computational neuroscience, Mozaik  (Antolík and Davison, 2013)  builds on both PyNN and Topographica  (Bednar, 2009). PyNEST  (Eppler et al. , 2009)  and PyNN developers collaborated with the INCF to improve the interoperability between these tools  (Djurfeldt et al. , 2014)  when using the Connection Set Algebra  (Djurfeldt, 2012). Finally, a number of tools have been built on the Python interface to NEURON  (Hines et al.
, 2009) , including morphforge  (Hull and Willshaw, 2014)  and LFPy  (Lindén et al. , 2014). Observing the rapid growth in adoption of Python in neuroscience over the last 6 years, which appears to continue to accelerate, it is clear that Python is here to stay, which augurs well for the growth, productivity, and rigor of computational methods in neuroscience.
This paper presents two formal models of the Data Encryption Standard (DES), a first using the international standard LOTOS, and a second using the more recent process calculus LNT. Both models encode the DES in the style of asynchronous circuits, i. e. , the data-flow blocks of the DES algorithm are represented by processes communicating via rendezvous. To ensure correctness of the models, several techniques have been applied, including model checking, equivalence checking, and comparing the results produced by a prototype automatically generated from the formal model with those of existing implementations of the DES. The complete code of the models is provided as appendices and also available on the website of the CADP verification toolbox. 4 http://cadp. inria. fr/demos/demo_38 5 See entry #2076 in the list of changes to CADP (http://cadp.
The present paper goes further and analyzes the fully asynchronous DES, describing formal models of the DES in two different process calculi, namely the international standard LOTOS  [12]  and the more recent LNT language  [3] , both supported by CADP. The LOTOS model of the DES was directly derived from the DES standard  [17]  to experiment with the application of LOTOS for the analysis of asynchronous circuits. In August 2015, the LOTOS model was rewritten into an equivalent LNT model to fulfill the expectations of the MARS workshop. Both models have been analyzed using different techniques, namely data abstraction, model checking, equivalence checking, and the automatic generation of a prototype software implementation. All these verification steps have been automated by an SVL (Script Verification Language)  [6]  script.
The rest of this paper is organized as follows. Section 2 briefly presents the data-flow architecture of the DES. Section 3 discusses modeling challenges and choices. Section 4 (respectively, 5)  presents the steps undertaken to assess the correctness of the model with (respectively without) data abstraction. Section 6 gives concluding remarks. Appendix A is the complete source code of the LNT model. Appendix B is the complete source code of the LOTOS model. Appendix C contains the C code required to generate a prototype with the EXEC/CAESAR framework. Appendix D provides the SVL script to execute the verification scenarios described in this paper.
Analysis of the Abstract Model Analyzing the DES with enumerative techniques is challenging, because it is unfeasible to enumerate all 64-bit vectors. A first approach is to abstract from the actual data values and to focus the analysis on the control part, e. g. , check whether the sixteen iterations are correctly synchronized. Redefining the BIT data type to contain a single value (instead of two values), automatically transforms all bit-vector types into singleton types and all functions operating on bit vectors to the identity function. 7 Due to this drastic abstraction, enumerating all possible inputs is trivial, enabling LTS generation without resorting to environments and compositional techniques  [7]. Direct LTS Generation and Equivalence between the LNT and LOTOS Models. Table  2  gives statistics about the LTSs generated directly from the abstract models.
The two models (LOTOS and LNT) yield LTSs equivalent for branching (but not strong) bisimulation (checked by PROPERTY 7 of the SVL script given in Appendix D). In both cases, the LTS minimized for branching bisimulation has 28 states and 78 transitions. The significant difference in LTS size between the LNT model and the LOTOS model is explained by the semantic difference in the symmetric sequential composition  [5]. The LOTOS operator ">>" generates an internal "i" transition, whereas the LNT operator ";" does not. Such a symmetric sequential composition (rather than a simple action prefix) is required whenever a process can read several inputs in parallel before producing its output. This is in particular the case for process P, which reads the output of the eight S-boxes. When these internal "i" transitions are removed by adding the pragma "( * ! atomic * )" to all occurrences of ">>", the LOTOS model yields an LTS of exactly the same size as the LNT model.
The LTS obtained after removing all offers (using appropriate renaming operations, i. e. , those applied to file des sample. bcg in PROPERTY 6 of the SVL script given in Appendix D) and minimization using branching bisimulation is shown in Figure  2. Compositional LTS Generation. Compositional LTS generation, i. e. , the bottom-up LTS construction alternating generation and minimization steps, is much more efficient. The initial steps of the SVL script given in Appendix D require at most 50 MB of RAM and generate the minimized LTS (28 states and 78 transitions) in less than 90 seconds. The success of compositional techniques on the LOTOS model triggered the development of the CHP2LOTOS translator  [10]  to provide the full power of CADP to the designers of asynchronous circuits. Model Checking.
These comparisons helped to spot and correct a handful of differences caused by typographic errors, i. e. , bad copying of the DES standard into LOTOS and LNT. The compilation and execution of the prototype implementation corresponds to PROPERTY 5 in the SVL script given in Appendix D. Although using a handful of tests is far from exhaustive, the structure of the DES with its iterations, permutations and bit operations and the fact that cipher heavily shuffles the input data lead to a coverage sufficient for the purpose of analyzing the control part. Model Checking. The generation of an LTS from the concrete model requires an environment to restrict the domain of possible input values. The model DES SAMPLE is such a variant of the concrete one, including a sequential environment providing a key and a data for a single encryption and checking the correctness of the output.
The direct generation of the corresponding LTS  (10,156,715 states and 75,933,635  transitions for the  LNT model, and 32, 219, 740 states and 259, 010, 596  transitions for the LOTOS model) requires less than 6 GB of RAM. The correctness of the computed result can verified by model checking a property expressing that the action on gate OUTPUT is eventually reached. A second verification is that after removing all offers, the LTS is included in the LTS of Figure  2. These verifications are carried out by the PROPERTY 6 in the SVL script given in Appendix D.
Conclusion This paper presents two formal models of the Data Encryption Standard, which might be an interesting benchmark example, because it is both complex and tractable (with current hardware and/or compositional techniques). For instance, it is sufficiently large to make interesting screenshots of the monitor of the distributed state space generation tool DISTRIBUTOR  [9]  (see also the DISTRIBUTOR manual page  10  ). These models also illustrate an interesting feature of LOTOS and LNT, namely the possibility to easily change the implementation of a data type to transform a prototype implementation into an abstract model adapted to formal verification. chronous Circuits and Systems (ASYNC'02), Manchester, United Kingdom,  IEEE, pp. 211-218, doi:10. 1109 /ASYNC. 2002. 1000311. [16]    The syntax and semantics of LNT is defined in the reference manual  [3].
C C Code for the EXEC/CAESAR Framework To generate a protoype from the LNT or LOTOS model using the EXEC/CAESAR framework, additional C code is necessary, namely the main program (for which the example provided with CADP 13 can be used) and so-called gate functions implementing the interaction with the environment. The DES prototype reads its inputs from the standard input and prints its results to the standard output. Each rendezvous corresponds to one line of input (respectively, output), following the syntax of LOTOS, i. e. , "G !O", where G is a gate name and O is a sequence of characters corresponding to the offer. For convenience, 64-bit vectors (for gates CRYPT, DATA, KEY, and OUTPUT) are represented by a sequence of sixteen hexadecimal digits, and Booleans (for gate CRYPT) by 0 (false) and 1 (true).
r f o r t h e g a t e o f t h e r e n d e z v o u s i n t h e c u r r e n t l i n e o f s t d i n * / s t a t i c c h a r CURRENT GATE  [ 6 ]  ;  The complete verification scenario of the asynchronous DES is executed by the following SVL script, using only sequential tools of CADP (i. e. , no distributed state space generation is required 15 ). The script is also available in the demo example on the CADP website 4.
r y f u n c t i o n t o c h e c k w h e t h e r t h e c u r r e n t l i n e o f t h e s t a n The SVL script first compositionally generates the LTS corresponding to the abstract LNT model DES ABSTRACT. lnt. The script then verifies several properties of the LNT models, using different techniques, such as model checking (for the temporal logic properties of Sections 4 and 5) and equivalence checking, but also the generation of a prototype from the LNT model DES CONCRETE. lnt and comparing its output for some example data and key with official results. These first steps can be easily adapted to use the LOTOS model instead of the LNT model. Finally, the LNT models are compared (using equivalence checking) with the corresponding LOTOS specifications, which are supposed to be located in a subdirectory called "LOTOS", together with an SVL script called "demo.
s p e c i f i c a t i o n DES ABSTRACT [ CRYPT, KEY , DATA, OUTPUT] : n o e x i t l i b r a r y BOOLEAN, NATURAL, BIT ABSTRACT , TYPES , PERMUTATION FUNCTIONS , S BOX FUNCTIONS e n d l i b b eh a v io u r DES [ CRYPT, KEY, DATA, OUTPUT] where l i b r a r y DES , CONTROLLER, KEY PATH , DATA PATH, CIPHER e n d l i b endspecB. 12 Specification with Concrete Bits: DES CONCRETEThis LOTOS specification can be used to generate a prototype implementation. It is not suitable for state space generation, because it would have to enumerate over all possible input values, i. e. , 64-bit vectors.
Acknowledgements. Some of the experiments presented in this paper were carried out using the Grid'5000 experimental testbed 11 built by Inria with support from  CNRS ,  RENATER, several Universities , and other funding bodies. I am grateful to  Hubert Garavel  for his suggestion to improve the model(s) and their presentation. I would like to thank  Edith Beigné ,  Francois Bertrand ,  Pascal Vivet  ( CEA Leti ),  Dominique Borrione ,  Menouer Boubekeur ,  Marc Renaudin  (TIMA), and  Gwen Salaün  ( Inria ) for discussions about asynchronous logic, the  CHP language , and the implementation of the DES in asynchronous logic.
This protein could form a nuclear RNP complex with an snRNA and then undergo retrotransposition (fig. 4d-f ). ORF2 A A A A L1 RNP complex L1 RNP complex snRNA ORF2 A A A A (d) ORF2 ORF2 A A A A ORF2 ORF2 ( snRNA-Processed Pseudogenes Are Common to All Mammalian Genomes We further aimed to analyze the U6 snRNA pseudogene distribution in all placental mammals with available assembled genomes (39 species; table 2). For this purpose, we developed a bioinformatics pipeline named ProRNAScan to analyze small RNA pseudogenes. This program arranges highly similar nucleotide sequences (identified by BLAST) in groups based on their structure and flanking sequences (the same four groups described in table  1 ). The pipeline is set by default with the selective parameters established for the human U6 snRNA analysis (i.
Materials and Methods In Silico Analysis for the Human Genome Sequences of the human snRNA genes were obtained at GenBank (http://www. ncbi. nlm. nih. gov/genbank/, last accessed March 20, 2015) using the following accession numbers: U1 (J00318), U2 (K02227), U4 (M15957), U5 (X04215), U6 (M14486), U11 (X58716), U12 (J04119), U4atac (U62822), and U6atac (U62823). The obtained sequences were used to perform BLAST search (using default parameters;  Altschul et al. 1997)  on Ensembl release 73 (http://www. ensembl. org/index. html, last accessed March 20, 2015). We limited our analysis to sequences having at least 90% identity with the reference gene and retrieved 3,512 sequences. For U2 and U6, due to the large number of hits, we further limited our analysis to sequences with at least 97. 5% identity.
Analyzed Genomes All the 48 analyzed genomes are indicated in table 2 and are accessible on the Ensembl web site: http://www. ensembl. org/ info/about/species. html (last accessed March 20, 2015). In our analysis, we used the Homo sapiens U6 snRNA reference sequence mentioned above (GenBank accession number M14486), as it is conserved in all mammals (with 100% identity). Although no annotated U6 snRNA gene was available for the lizard and birds genome, the use of human U6 snRNA sequence in an initial BLAST search allowed us to confirm the extended conservation of U6 snRNA sequence to the lizard and birds genomes. We used the xenopus U6 snRNA reference sequence (GenBank accession number NR_033272) to screen the xenopus genome.
Bioinformatic Analysis The program, named ProRNAScan, was created to analyze the snRNA pseudogenes from the 48 genomes mentioned above, and is available at http://endorphine. igh. cnrs. fr (last accessed March 20, 2015). Other genomes, available from the Ensembl web site, can be added upon request. The web interface was made interactive and efficient by using Ajax and JQuery. The backend service was developed using Perl on an Apache web server. The pipeline is set by default with the selective parameters established for the human U6 snRNA analysis (i. e. , 97. 5% identity to the referring sequence and at least 26 nucleotides in length, 10 for the e value and 10 for the size of the TSD). The end user can modify these parameters. For detection of small noncoding retrotransposed sequences, the program initially performs an homology search using BLAST (with the default parameters), generating a first set of potential hits.