dataesr/scientific-paragraphs-categorization huggingface dataset:
Acoustic Stimuli and Presentation Stimuli were presented in as ound-attenuated chamber (mac3, Industrial Acoustics Corporation). All stimuli were composed of randomized sequences of pure and Shepard tones  [7]. AS hepard tone is ac omplext one built as the sum of octave-spaced pure tones (using aflat spectral envelope). AS hepard tone can be characterized by its position in an octave,t ermed pitch class (inu nits of semitones), w. r. t. ab ase tone. Across the entire set of experiments the duration of the tones was0. 1 sa ta no verall levelo f7 0d BSPL, and each tone presented 5-20 times. The impulse response of the speaker wascompensated to achieve aflat calibration overthe range of 0. 08-35 kHz by convolving the stimulus with the inverse of the speaker's impulse response. Stimuli were generated in Matlab using custom-written code sampled at 100 kHz, and then D/A converted via aDAQ-card (NI-6259, National Instruments).
Data Analysis First, recordings were bandpass (300-7000 Hz)fi ltered, and spike-sorted using custom-written code. Responses were then aligned to stimulus onsets and collected and averaged across stimulus repetitions. Collecting the responses for all stimuli one obtains the so-called encoding matrix (Figure  1top ). Forvisual convenience, the encoding matrix is here shown sorted by stimulus frequency. However, the analysis belowdoes not takesorting into account. In classical RSA (Figure  1A  top), adistance matrix between stimuli is defined as D(i, j) = 1 -C(i, j) + (1) where C(i, j): = n ∈ Neurons N i (n)N j (n)i st he correlation between population responses N i and N j for different stimuli S i and S j ,r espectively,a nd the '+'i ndicates taking only the positive part  [6]. Hence, the distance between stimuli is measured as the degree of difference in their population responses.
Nevertheless, other well-known software alternatives require some skills in the corresponding programming language to deal with the spatial data. This is the case of some specialized packages in R (R Core Team 2016), the library PySAL  (Rey and Anselin 2007)  written in Python (Van Rossum 1995), the toolbox for spatial econometric models written by  LeSage (2009)  in MATLAB (MATLAB 2017), some functions, also in MATLAB, to estimate static and dynamic spatial panel data models developed by Elhorst  (Elhorst et al. 2013) , and a suite of commands for spatial data in SAS (SAS Institute Inc. 2013) or Stata  (StataCorp. 2015). Bivand and Piras (2015)  compare the results obtained by using different software alternatives and conclude that all of them provide similar results. In this overview we focus on R, for the following reasons 6  : • it is a well-tested free software with a growing number of packages in all statistical fields (spatial analysis included); • it has a huge community of users; • the possibility to combine functional programming with object-oriented programming  (Chambers 2016 ) allows the developers to build new packages making use of the existing ones; • it allows to estimate most of the spatial econometric models exposed in this chapter including both parametric models (for cross-sectional and static panel data) and semiparametric models.
The R packages spdep  (Bivand 2013)  and sp  (Bivand et al. 2013; Pebesma and Bivand 2005 ) facilitate the creation, transformation and manipulation of spatial objects, neighborhood matrices and the computation of descriptive measures of spatial autocorrelation. Moreover, the package spdep allows researchers to estimate the whole set of cross-sectional spatial autoregressive models exposed in Sect. 2. 1 including SAR, SEM, SDM, SLX and SAC models using either ML or GMM estimation in an efficient way. Furthermore, this package also permits us to compute the marginal effects and make inference on their values. To extend the range of standard spatial models considered, Piras (2010) created the sphet package for estimating and testing parametric spatial models with heteroskedastic innovations using estimation procedures based on GMM.
2013). Focusing on semiparametric spatial data models (Sect. 3), McMillen (2013) has written the McSpatial package which includes routines to estimate nonparametric and conditionally parametric versions of spatial linear regression and spatial models with binary dependent variable. It mainly uses kernel techniques to perform the nonparametric estimations. Moreover, the package GWmodel  (Gollini et al. 2015; Lu et al. 2014 ) deals with geographical weighted (GW) models, and includes functions for computation of GW summary statistics and regression, GW principal components analysis, and GW discriminant analysis. The techniques to estimate MGWR-SAR models discussed in Sect. 3. 1 are already included in the forthcoming R package gwrsar  (Geniaux and Martinetti 2017). Finally, considering semiparametric regression models that include spatial or spatiotemporal trends, both packages mgcv  (Wood 2006 ) and R2BayesX  (Belitz et al.
Acknowledgement. This work has been prepared within the activities of the  EU  project  COST Action IS1104  "The  EU  in the new complex geography of economic systems: models, tools and policy evaluation". The authors are grateful for financial support. Acknowledgements. The work of  Román Mínguez  was supported by the research project  MTM2014-52184  and  ECO2015-65826-P  from the  Spanish Ministry of Economy and Competitiveness. Acknowledgement. We would like to acknowledge financial support from  COST Action IS1104  "The  EU  in the new economic complex geography: models, tools and policy analysis". Acknowledgements. The authors thank the participants at the GeComplexity Conference in Crete 2016 for valuable comments and suggestions on an earlier draft of this paper. Special thanks go to  J.
Defective interfering (DI) genomes, or defective viral genomes (DVGs), are truncated viral genomes generated during replication of most viruses, including live viral vaccines. Among these, "panhandle" or copy-back (cb) and "hairpin" or snap-back (sb) DI genomes are generated during RNA virus replication. 5 ′ ′ ′ ′ ′ cb/sb DI genomes are highly relevant for viral pathogenesis since they harbor immunostimulatory properties that increase virus recognition by the innate immune system of the host. We have developed DI-tector, a user-friendly and freely available program that identifies and characterizes cb/sb genomes from next-generation sequencing (NGS) data. DI-tector confirmed the presence of 5 ′ ′ ′ ′ ′ cb genomes in cells infected with measles virus (MV). DI-tector also identified a novel 5 ′ ′ ′ ′ ′ cb genome, as well as a variety of 3 ′ ′ ′ ′ ′ cb/sb genomes whose existence had not previously been detected by conventional approaches in MV-infected cells.
This program characterizes all potential DI genomes in the population, contrary to classical PCR amplification, which requires specific primers, assuming that the type of DI genomes searched is known. Moreover, DI-tector allows the use of a unique data set  to detect various types of DI genomes, for instance from coinfected samples. DI-tector is available as a free python script at www. di-tector. cyame. eu. Graphical outputs, such as scatter-plot, chord diagram, sequence logo and linear representation of DI genomes, can be generated using the complementary online DI-tector (www. di-tector. cyame. eu). One of the key steps of DI-tector is unmatched reads segmentation (Fig. 2ii ). During this segmentation step, reads are split to detect the recombination junction, which occurred at least after the first X, and before the last X, nucleotides of the read (where X is defined by the user).
For instance, in MV-and SeV-infected cell samples, reads may come from viral genomes or viral transcripts. Analysis of nontranslated regions may be used for DI genome quantification. This did not apply to our data since the coverage at genome extremity was lower than the average coverage. Using nontranscribed intergenic regions may also be a solution, but should be addressed for each virus and no automatic estimation of the quantity can be done. Moreover, only relative abundance may be assessed. A solution to quantify the DI genomes detected with DItector is to perform qPCR on the samples using specific probes overlapping the junction  (Komarova et al. 2013; Mura et al. 2017) , as the exact sequence of the recombination junction is given by DI-tector. Predictive performance assessment of DI-tector using different experimental and simulated data sets revealed a robust specificity and sensitivity (Fig.
MATERIALS AND METHODS Our DI genome detection protocol comprises four main steps: (i) alignment of reads against host and viral genomes, (ii) unmatched and mismatched reads segmentation, (iii) second alignment of reads against viral genomes, and (iv) analyses of the matched reads, as detailed below (Figs. 2  and 3 ). These steps involved commonly used preexisting tools such as BWA  (Li and Durbin 2009)  and SAMtools  (Li et al. 2009) , which demand the minimum hardware requirement. Analyses and graphical representation of the results are proposed, respectively, as a python script freely available at www. di-tector. cyame. eu and a webtool at the same address. Figures  4, 6 , 7, 8 and Supplemental Figures  S1, S3 , and S4 have been generated using a custom R script and R Studio (RStudio Team 2016).
Raw data DI-tector pipeline proceeds with adaptor sequence trimmed fastq files generated from the sequencer. Reads quality may be evaluated by FastQC (www. bioinformatics. babraham. ac. uk/projects/ fastqc/) and reads can be quality trimmed when necessary. Fastq files (Single-end Read) for MV and recombinant MV that is unable to express the V protein (rMV-ΔV) have been previously generated in our laboratory  (Sanchez David et al. 2016). Briefly, infected HEK-293 cells stably expressing One-STrEP-tagged RIG-I or Cherry protein were lysed with MOPS lysis buffer (20 mM MOPS-KOH pH7. 4, 120 mM of KCl, 0. 5% Igepal, 2 mM ß-Mercaptoethanol), supplemented with 200 unit/mL RNasin (Promega) and Complete Protease Inhibitor Cocktail (Roche). An aliquot of each cell lysate was used to perform total RNA purification using TRI Reagent LS (Sigma).
The remaining cell lysate was kept to purify the RIG-I/ RNA, or Cherry/RNA complexes by affinity chromatography using StrepTactin Sepharose High Performance beads (GE Healthcare). RNAs that had co-precipitated with either RIG-I or Cherry protein were isolated using TRI Reagent LS. RNA was dissolved in DNasefree and RNase-free ultrapure water. Extracted RNAs were analyzed using the Nanovue (GE Healthcare) and Bioanalyser RNA Nano Kit (Agilent). 300 ng of each RNA sample was treated for library preparation using the TruSeq Stranded mRNA Sample Preparation Kit (Illumina). Sequencing was performed on the Illumina Hiseq2000 platform to generate single-end 51 bp reads bearing strand specificity (Sanchez  David et al. 2016). Three biological experiments were performed. Data sets of Sendai virus (SeV) infected Huh-7 cells were retrieved on  NCBI (www.
ncbi. nlm. nih. gov/sra, accession numbers SRX2600182 and SRX2600183). Briefly, RNA extraction of SeV infected cells was treated with DNase. Directional RNA-seq libraries were generated using the PrepX RNA-seq for Illumina Library Kit (WaferGen Biosystems). Libraries were pooled and sequenced on the NextSeq 500 (Illumina) targeting 10M PE reads at 150 read length. Reads were demultiplexed, which removed barcodes and sequencing adapters. The latter sample named SeV_RZ was treated with the Ribo-Zero Gold rRNA Removal Kit (Human/ Mouse/Rat) (Illumina) prior to library preparation. Reference sequences used in this study were GRCh38. p11 for Human genome (GCF_000001405. 37_GRCh38. p11_genomic), NCBI reference sequence FJ211590. 1 for MV (strain Schwarz), and NC_001552. 1 for SeV. Fasta files containing human and viral genome sequences were indexed using the bwa index tool.
Assessment of DI-tector detection performance The detection performance of DI-tector was evaluated using three simulated data sets generated independently. They respectively contain 500,000 simulated reads covering junctions of 5 ′ copy-back ("5 ′ cb"), 3 ′ copy-back ("3 ′ cb") DI genomes, or DI genomes with insertion/deletion ("INDEL"). These data sets were generated as follows: Two times 500,000 random values from 1 to 15,894 (MV genome length) were generated, respectively, for BP and RI sites. This step was repeated individually for each data set. For each combination of BP and RI values, a random value (J) between 1 and 50 (51 nt reads length -1) was generated. We generated 51-nt-long reads since the experimental data set for MV and rΔV-MV samples contained 51-nt-long reads. For the data set "INDEL," sequences of MV genome from BP to BP + J and RI to RI + (51 -J) were combined.
For the data set "5 ′ cb", the first part of the read (i. e. , from BP to BP + J) was reverse complemented. In a similar manner, the second part of the simulated reads [i. e. , RI to RI + (51 -J)] was reverse complemented to generate "3 ′ cb" data set. Sensitivity (Sn) and specificity (Sp) were calculated as follows: Sn = TP/(TP + FN); Sp = TN/(TN + FP). TP (true positive) and FN (false negative) are respectively correctly and incorrectly detected 5 ′ copy-back junctions in "5 ′ cb" data set. FP (false positive) and TN (true negative) are respectively clustered as 5 ′ copy-back junction or not in "INDEL" data set. Data sets from noninfected cells (total or beads) (unpublished data) were also analyzed to estimate putative FP from host material. Data sets used in Supplemental Figure  S4  were similarly generated.
ACKNOWLEDGMENTS The authors thank  Dr. Elias Hage ,  Dr. Mickael Orgeur ,  Dr. Guillaume Cornelis , the  Transcriptome and Epigenome Platform of Institut Pasteur , specifically  Rachel Legendre , and all members of " Unité de Génomique Virale et Vaccination"  for advice and discussions. We thank  Dr. Bernd Jagla  ( "Hub Bioinformatique et Biostatistique," Institut Pasteur ) and  Dr. Etienne Simon-Loriere  ("Génomique évolutive des virus à  ARN," Institut Pasteur)  for critical reading of the manuscript. We also thank  Ségolène Gracias  for help in choosing the online DI-tector logo. This work was supported by the  Institut Pasteur , the  "Centre National de la Rercherche Scientifique,"  and funding from  Agence Nationale de la Recherche  ( ANR-16-CE15-0025-01  to N. J. ). M. M. was supported by the  Institut de Recherche Biomédicale des Armées (IRBA).
In the system we use for our experiments, the most precise method is based on data-link layer timestamping and predictions of the transfer time (as defined in Section 3. 3). With this approach, a module gets synchronized by a single timestamped message from its parent in the synchronization tree incurring little message overhead. Furthermore, modules use linear regression to compensate for clock skew. We implemented our protocol and evaluated it on the Blinky Blocks system  (Kirby et al. , 2011) , both on hardware 1  and in the Visi-bleSim simulator 2   (Dhoutaut et al. , 2013). We provide two videos of MRTP running on the Blinky Blocks hardware platform to illustrate the necessity, the effectiveness and the robustness of MRTP 3, 4. In this article, we show that MRTP is able to manage systems composed of up to 27, 775 Blinky Blocks.
Furthermore, experimental results show that MRTP is able to successfully maintain a Blinky Blocks system synchronized to a few milliseconds, using few network resources at runtime, although the Blinky Blocks use low-bitrate communications (38. 4 kbit/s) and are equipped with a very low accuracy (10, 000 parts per million (ppm)) and poor resolution (1 ms) clocks. Supplementary video related to this article can be found at https:// doi. org/10. 1016/j. jnca. 2017. 12. 018 The following are the supplementary data related to this article: The rest of this paper is organized as follows. Section 2 offers an overview of the existing time synchronization protocols. Section 3 details the system model and assumptions. Section 4 describes MRTP. Section 5 describes the technical characteristics of the Blinky Blocks, the target platform.
2 ) to collect time reference points < t, L M i (t) >, with i the block unique identifier, every 10 s during 7 h (see Fig. 3 ). The real time t was provided by a computer. We assumed the computer clock to be perfect. We use the PRED method to compensate for communication delays. Fig. 4  shows the distribution of the parameter values obtained using polynomial regression with R. The parameters D and y 0 seem normally distributed. As a consequence, we randomly generate clock parameters following normal distributions with the corresponding mean and standard deviation (see Table  2 ). Noise signals are the residual standard errors. We extracted the 5 noise signals and replay them in our simulations. A message is sent over the link into a frame composed of 21 bytes minimum: 17 bytes of payload data and 4 bytes of control (i.
T transfer ≈ ( L M 2 (t m ′ r ) -L M 2 (t m s ) ) - ( L M 1 (t m ′ s ) -L M 1 (t m r ) ) 2 (6) We experimentally measured Ttransfer for 300,000 two-way message exchanges between neighbor modules in sparse and compact Blinky Blocks systems (see Fig. 5 ). We observed that Ttransfer is always between 5 and 7 ms. On average, Ttransfer of 21-byte long frames varies slightly around 6 ms depending on the number of simultaneous communications. Moreover, at the resolution of 1 ms, the transfer time of identicallength frame is fairly constant. A transfer time of 6 ms for a 21-byte long frame corresponds to a transfer rate of 28 kbit/s. Based on these results, we consider that the transfer rate of a message can be estimated by Rtransfer = 28kbit∕s. As a consequence, we use Equation (  7 ) to estimate the transfer delay of a message and to compensate for communication delays in the PRED method.
Because of the poor accuracy of the Blinky Blocks hardware clocks, we expect synchronization error using our protocol to be greater than 1-2 ms. Thus, within a few hops, G(t) can be used as a reference time to estimate the synchronization error of the Blinky Blocks. Upon reception of a synchronization message, a module M i estimates its relative synchronization error to the global time by εM i (t) = G M i (t) -G(t). We do not use virtual modules any more in the rest of the evaluation.
As announced in Section 6. 1. 2, MRTP can effectively synchronize the Ball(  27 ) system, composed of 27,775 modules, to less than 40 ms. Indeed, it synchronizes this system to 17 ms in average and to 24 ms at worst. 6. 2. 4. Communication efficiency 6. 2. 4. 1. Number of messages. Fig. 14  shows the average number of messages sent per module and its decomposition according to message types. We consider three types of messages: the messages due to the leader election process, the ones due to the tree infrastructure creation and the synchronization messages. As awaited, ATS and WMTS decentralized synchronization protocols use in average more messages per module than MRTP, MLE_TPSN and PulseSync centralized protocols. In addition, PulseSync, which uses network-wide floodings, generates in average more messages per module than MRTP and MLE_TPSN, which use a tree-like structure.
Message queue usage. We measured the maximum message queue size reached by the modules taking into account both the incoming and the outgoing messages. We observed that for any module, the ratio of the maximum reached queue size to the number of neighbors of that module, remains below or equal to three, regardless of the size of the networks for all the protocols except for PulseSync. For Puls-eSync, the ratio reached the value of 4. 5. Thus, nor the leader election process, which involves network-wide flooding(s), nor the actual synchronization phases overwhelm the network. The traffic generated by the synchronization protocols remain well controlled and modules do not require a lot of memory space to store incoming and outgoing messages.
Acknowledgments This work has been funded by the " Programmable Matter "  ANR  project ( ANR-16-CE33-0022-02 ), the  French  " Investissements d'Avenir program ", the  ISITE-BFC  project ( ANR-15-IDEX-03 ), the  Labex ACTION program  ( ANR-11-LABX-01-01 ) and the  Mobilitech  project.
Our partners calculate that an initial input data set of 153000 videos (of 3 minutes each), corresponds to 320 A related problem to randomly synthesizing videos is that practitioners ignore what kinds of situations are covered or not by the set of videos. Therefore, it is not possible to ensure the quality of the test-suite for detection algorithms in all situations. Overall, more automation and control are needed to synthesize video variants and cover a diversity of testing scenarios. The first step for automation support was taken by our partners. They created a video generator to produce customized videos based on user preferences that were hard-coded during the first versions. The left-hand side of Figure  1  shows this old approach where the only actors are the developers. They had to comment lines or modify variable values directly in the video generator code to change the physical properties and objects that appear in each video.
When the video generator was more stable, the developers decided to create configuration files to communicate input values instead of hard-coded them. In particular, they employed Lua configuration files which have a simple structure based the pattern parameter = value. Then, developers used Lua code and proprietary C++ libraries, developed by a MOTIV partner, to process those configuration files and execute algorithms to alter, add, remove or substitute elements in base videos  1. The Lua configuration files used helped to decouple implementation from input data, however, their simplistic nature presented at least three drawbacks: i) they lack of relationships and constraints between configuration options; this information is very important to scope the family of videos and to exclude invalid configurations; ii) every change in the video generator requires to change n configuration files, thus, this task becomes error prone and tedious as the n value is high (about 500 in the first round of experiments according to our partners); and iii) they require that developers understand very well the implementation details of the video generator.
R12. Benefit automated support. VM models should be read by a processing tool to provide automated analysis operations (e. g. , to check that the model is valid or return pair-wise covering), to generate Lua configurations files, and to control the generation of the videos related to those configurations. It is important to note that there are too many possible combinations of features and attribute values. Therefore, part of the challenge is to determine the criteria to define which are the most important combinations to generate. The objective is to find constructs in the language that have a positive effect in the performance of the automated analysis operations (e. g. , to retrieve significant pair-wise coverage configurations, or prune not valid but too similar configurations). → C38-C39.
However, we discovered that new frameworks for language development make these tasks less complex and or even fully automated. For instance, we used Xtex 4  to generate the VM editor and parser, based only on the VM grammar definition. Using Xtext, we expended about one hour to create a working VM editor for the first iteration of VM, three days for the second iteration, and about four days for the third iteration. Admittedly, the most difficult part was to understand how to model and interpret nested expressions and operators precedence in the constraints block. An extra effort for us was the connection with the Lua code and the configuration files for the VM model to be aligned with the schema of the configuration file exploited by the video generator. We needed technical exchanges (by emails), beyond meetings with video.