dataesr/scientific-paragraphs-categorization huggingface dataset:
Annotation methodology validation As explained in Section 3. 2. 3, we cross-annotated the dataset to allow for the assessment of the reliability of the annotations produced. We consider that obtaining reliable annotations validates the definition of the taxonomy and the annotation process, and ensures the usability of the dataset. The information that we use for this assessment is the percentage of inter-annotator agreement between the three annotators in the annotated classes. For the rest of this paper, we will just use the term agreement when referring to inter-annotator agreement. Note that we have not removed any audio file from the dataset based on the agreement information. We define two different levels of agreement: full agreement, which happens when all three annotators have annotated the same class; and partial agreement, which happens when at least two annotators have annotated the same class.
We compute the percentage of full agreement (%FA af ) and partial agreement (%PA af ) in an audio file as the time during which the agreement level is reached (t FA and t PA , respectively) divided by the duration of the audio file (T af ) as shown in Eqn. 1 and Eqn. 2. To obtain the percentage of full agreement (%FA) and partial agreement (%PA) for the whole dataset, we compute the mean for all N audio files as shown in Eqn. 3 and Eqn. 4. (2) ( ) = = ∑ 1 1 % % N af n FA FA n N (3) ( ) = = ∑ 1 1 % % N af n PA PA n N (4) These values can be computed considering all the classes in the taxonomy, but also for the two mappings of these classes that we show in Table  2  shows the %FA and %PA when considering all classes as well as when applying both mappings. It also presents these agreement percentage values for each pair of annotators, i.
Examples of this can be background tones, musical sound effects such as a church bell or a ringing phone or even experimental music or music of uncommon styles. The second source of disagreement appears due to a different interpretation of what components of the audio belong to the music. This happens, for instance, when the audience claps following the beats of the music or when there are soft noises overlapping with the music that some annotators may find irrelevant. This can lead to strong differences in the annotation and it represents a significant percentage of the parts of the dataset with disagreement.
Content distribution After the cross-annotation process, we obtain three different annotations of the same content. Table  3  shows the content distribution as annotated by each annotator for the complete taxonomy and both mappings. We observe that the percentages are similar for all annotators: first, all annotators have considered that around 50% of the dataset is No Music, which implies that the other 50% contains music that appears either isolated or mixed with non-music sounds. This means that OpenBMAT is balanced in terms of music and nonmusic content. Second, the part of the dataset containing music is approximately distributed with a 30%/70% proportion between the RMLE mapping Foreground Music and Background Music classes, respectively. Also, if we divide the dataset in terms of isolated and mixed classes as explained in Section 3.
Metadata and Storage With metadata we refer to all information related to the audio files in OpenBMAT. There are two sources of metadata per audio file: the annotations and the agreement. The annotations include the three original annotations as well as their MD and RMLE mappings. In total, there are nine annotations per audio file. The agreement metadata contains the %FA af and the %PA af of each audio file for the original annotations and both mappings, and the set of intervals with either full or partial agreement. These intervals give potential users the possibility to train or test their algorithms using, for instance, only the subset with full agreement. All this metadata is provided in JSON format. The metadata also includes the annotations in two additional formats: (1) as exported from BAT (one CSV file for each annotator) and (2) as separate TSV files for each audio file, annotator and taxonomy.
Apart from the metadata and the audio, OpenBMAT also contains: • A predefined split in 10 subsets to allow for K-fold cross-validation. We have randomly assigned each audio file to a subset and the resulting subsets preserve the original proportion of the RMLE mapping classes. • A python module with utilities such as (1) the generation of the annotations in JSON and TSV formats from BAT annotations, (2) the generation of the full and partial agreement audio subsets and (3) the possibility to load the using the open evaluation library used in the DCASE challenge. 12 The DCASE challenge is an international competition similar to MIREX, but exclusive to scene and event analysis methods. • A README file including a general description of the dataset and all the details about its structure and contents.
Conclusions Being aware of the current industry needs, we have designed OpenBMAT: the first music detection dataset to include annotations about the loudness of music in relation to simultaneous non-music sounds. OpenBMAT is an open dataset, and in comparison with the other publicly available music detection datasets, it is the only one that encompasses two essential features: (1) it contains a significant amount of multi-class audio files, and (2) the music appears both isolated and mixed with different types of non-music sounds. All these characteristics make OpenBMAT the most complete open dataset available for the task of music detection and the estimation of its relative loudness. To be able to assess the annotations reliability, three annotators have cross-annotated OpenBMAT. The analysis of these annotations produces a full agreement of 94.
78% when using the MD mapping and 89. 1% when using the RMLE mapping. When considering all classes, the 3 annotators completely disagree only in 3. 25% of the content. We have included agreement information for each audio file in OpenBMAT, specifically, the %FA af and the %PA af of each audio file and the segments with full and partial agreement. This can be useful for training as well as for testing of algorithms, as we have proved through the evaluation of a state-of-the-art algorithm. The error analysis of this evaluation has also revealed that OpenBMAT contains audio that is challenging to current state-of-the-art music detection algorithms. The metadata in OpenBMAT can be improved by adding more annotators to increase the reliability of the annotations even more. It can also be expanded through the creation of annotations using taxonomies related to other tasks or by including more information of each audio file such as its quality, its sound level, etc.
Notes 1 https://www. music-ir. org/mirex/wiki/2018:Music_ and/or_Speech_Detection. 2 https://createurs-editeurs. sacem. fr/brochuresdocuments/regles-de-repartition-2017. 3 www. seyerlehner. info/download/music_detection_ dataset_dafx_07. zip. 4 https://labrosa. ee. columbia. edu/sounds/musp/ scheislan. html. 5 http://www. openslr. org/17/. 6 opihi. cs. uvic. ca/sound/music_speech. tar. gz. 7 https://librivox. org. 8 https://www. bmat. com/. 9 https://tech. ebu. ch/docs/r/r128. pdf. 10 https://www. music-ir. org/mirex/wiki/MIREX_ HOME. 11 https://www. ismir. net/. 12 https://github. com/DCASE-REPO/dcase_util.
Acknowledgements We thank the annotators for the effort they invested in the annotation of OpenBMAT. We also thank  Alex Ciurana  from  BMAT  with whom we have discussed issues essential to the construction of this dataset. We thank  Brisa Burriel  for her advice on the best way to make OpenBMAT available to the research community and  Sonia Espi  for providing the means to do so. Finally, we thank the  Catalan Industrial Doctorates Plan  for funding this research.
We will also show momentarily that such 3-component types should in general be avoided as they lead to lower performance, since most if not all modern hardware are designed around power-of-two types (which is the reason why the OpenCL type is aligned to four components). Finally, we will assume that the standard operations (component-by-component addition, subtraction, and multiplication, multiplication by a scalar, dot product) on the small vector types have been defined, in the usual manner. (OpenCL C defines these as part of the language, for CUDA appropriate overloads for the common operators must be defined by the user. ).
Listing 2. Particle system with stream processing: array of structure (left) versus structure of array (right). Further optimizations, particularly important on older architectures, can be achieved with the sacrifice of some memory, to provide the position and velocity with a fourth (unused) component, as illustrated in Listing 3 (left), resulting in better bandwidth usage and thus faster execution; moreover, additional frequently used data may be stored in the fourth component, if needed (e. g. , in GPUSPH we store the mass in pos. w and the density in vel. w). The benefits of the discussed strategies are exemplified in Table  1  for a simple three-dimensional implementation of PSO. The specific values will obviously generally depend on the specific compute kernel as well as on the specific hardware.
, most of which are executed twice due to the predictor/corrector integration scheme used). Working without a neighbor list, the runtime cost of the search would have to be paid for each execution of a kernel with particle-particle interaction, increasing the runtime of a single operation by over 50%. The neighbor list is therefore a better choice for performance. On the other hand, on a typical simulation in GPUSPH, the neighbor list is also responsible for the highest memory allocation, even including the double buffering required for most data arrays: indeed, all of the particle properties combined take between 100 and 300 bytes per particle (depending on the formulation being used), whereas for the neighbor list, we need to store, in the simplest cases, 128 neighbors, leading to an occupation of 512 bytes per particle.
With this strategy, all strictly inner particles will be sorted first, followed by all inner edge particles, and finally by outer edge particles. Since outer edge particles will be sorted consecutively in memory, receiving data about them will be more efficient; similarly, sending inner edge data over will be made more efficient by the coalesced layout. Note that this cell sorting strategy does not completely eliminate the need for multiple transfers; it does however help to reduce it significantly, especially when combined with linear cell indexing and the appropriate choice of order of dimensions for linearization. For this reason, GPUSPH offers a (compile-time) option to allow customization of this choice that in our experience can have performance benefits of up to 30%.
A typical circumstance where one cannot avoid taking the square root is normalization of a vector, in which each component needs to be divided by the length of the vector; in some applications this is such a frequent (and slow) operation that fast, but less accurate implementations are used, such as the fast inverse square root  [35]  popularized by its use in id Software Quake III: Arena video game  [36]. While games can afford to sacrifice accuracy for performance, this is not the case in scientific applications, for which a significant issue in vector normalization (and similar operations) is numerical stability: when the vector has components which are very close to zero, a naive computation of the norm may lead to underflow, potentially resulting in a final division by zero during normalization; conversely, very large components can lead to overflow of the inner summation before the root extraction.
Workers for hardware abstraction Refactoring the execution role into a separate Worker class has several advantages. The most important, as mentioned above, is that having a separate Worker class provides a solid ground to expand the code to support multiple GPUs (with each Worker taking control of a separate device). Additionally, with the correct design, wider hardware support can be implemented by making the Worker class itself an abstract class, implementing only the common code, such as the evolution logic in the case of smart workers, or the command dispatch table in the case of dumb workers. Derived classes would then implement the hardware-specific details such as the actual kernel execution or the host/device memory transfers. For example, one could have a GPUWorker for execution on GPU and a CPUWorker for execution on CPU  [26] ; the GPUWorker class itself could be further specialized in a CUDAWorker and an OpenCLWorker, when support for both APIs is desired.
The next layer can be implemented as a GenericBuffer class template that depends on the data type and number of components of the buffer, so that GenericBuffer<float2, 3>would be able to handle storage and typed access to perparticle symmetric tensor data (encoded in three float2 per particle). Note that the Buffer class template still does not have any actual allocation logic: its only purpose is to provide the correct base class for the named properties of each particle (e. g. , position, velocity, etc. ). The allocation logic is delegated to derived classes such as HostBuffer (that would use malloc/free or new/delete), CUDABuffer (using cudaMalloc/cudaFree), and CLBuffer (using clCreateBuffer/ clReleaseMemObject). Finally, a collection of buffers is managed by a BufferList that maps symbolic names to the concrete class implementing the buffer with the specific symbolic name.
Since different variants of a particle system will instance different subsets of all possible buffers, the mapping will in general be sparse, and it is therefore better to use a dictionary type such as std::map (or language equivalent) to implement it. This is particularly true for the bitmask choice of symbolic names. Moreover, since each symbolic name maps to a buffer with a different data type, the mapping will generally be between symbolic names and AbstractBuffers. Downcasting to the correct Buffer<symbolic_name> type can be done in specific template methods, where the symbolic name is known as compile type. Our BufferList class, for example, exposes a template getData method that returns a pointer of the correct type for the given symbolic name, again using the buffer traits to deduce it; some example of its usage are illustrated further on.
When the user simulation setup is compiled, only the specific combination of parameters will be enabled and compiled for. An alternative solution is to rely on the specific possibility offered with GPU programming, to compile the device code at runtime. This feature has always been available with OpenCL (in fact, OpenCL requires runtime compilation of the device code), and it has been recently made available in CUDA via the NVRTC library. The main downside of the compile-time selection is that the software must always be distributed in source form, with several implications in terms of userfriendliness and maintenance. Downsides for runtime compilation include the limited support for older version of CUDA, when relying on this proprietary solution, and the potential time loss at the beginning of each execution (which may or may not be offset by any caching the runtime compilation engine might do).
C++ SFINAE versus C preprocessors for compile-time specialization Implementing multiple variations of a kernel (or function used by a kernel) is generally nontrivial, as the functions may have different sets of parameters and different private variables and may operate differently even on data that is present in all or most of them. The objective is therefore to isolate the variant-specific parts from the common parts, avoiding code repetition. When using runtime compilation for the device code and a C-based language such as OpenCL C, the only way to achieve this is to fence nonrelevant parts of the code with appropriate preprocessor directives, as illustrated in Listing 10 (left). Code fencing can be factored out, and sometimes reduced, by collecting data into conditional structures and refactoring computations into conditional functions; the resulting code is slightly more verbose (Listing 10, right), but the optional features are better isolated, improving the maintainability of the code.
Note that the conditional structure in this example cannot be extended to the kernel parameters and private variables itself, due to the impossibility for global array addresses to be member of structures shared between host and device, which further limits the possibility to initialize the conditional parts of the private variable structure with appropriate conditional functions. (This is a limitation of OpenCL C; alternative solutions are possible using the Shared Virtual Memory feature introduced in OpenCL 2. 0 and supported by some implementations as an extension on older versions of the standard. ) When the device code can be written in C++ and global arrays pointers are made available in the same form to both the host and device (e. g. , with CUDA), the language itself provides powerful meta-programming techniques that can be leveraged to eliminate the need for a preprocessor, allowing multiple specialized implementations to coexist.
We also see why the empty structure needs to be a template: if this was not the case, and both XSPH and the stress tensor computation were disabled, the kernel parameters structure would have empty as a base class twice, which is not allowed by the standard; with our template approach, the two empty base classes are now formally distinct types: empty<xsph_kernel_params> and empty<stress_kernel_params>. The sample code also shows the advantage of the BufferList class described previously and its typed buffer access methods. On the device side, we can use the same approach for the private variables of the kernel (Listing 12). Finally, we need to define the individual process functions. For this, we need separate overloads depending on whether the priv structure has the specific members or not.
Acknowledgements. FSM and PT would like to acknowledge and thank the  ERC  for funding this work under the  Horizon 2020 program  project  ATMO  (ID:  757858 ). NJM is part funded by a  Leverhulme Trust   Research Project Grant  and partly supported by a  Science and Technology Facilities Council  Consolidated Grant ( ST/R000395/1 ). JL acknowledges funding from the  European Research Council (ERC)  under the European Union's  Horizon 2020 research and innovation program  (grant agreement No. 679030/WHIPLASH ). GC was supported by the  Programme National de Planétologie (PNP)  of  CNRS-INSU  cofunded by  CNES. IB thanks the  European Research Council (ERC)  for funding under the  H2020 research and innovation programme  (grant agreement  787361  COBOM). FD thanks the  European Research Council (ERC)  for funding under the  H2020 research and innovation programme  (grant agreement  740651  NewWorlds).
Cheeseman & Stutz, 1996) , Landsat satellites images (P. Cheeseman & Stutz, 1996) , body pattern in the common cuttlefish  (Crook, Baddeley, & Osorio, 2002) , patterns between rich and poor countries  (Ardiç, 2006) , network traffic  (Erman, Arlitt, & Mahanti, 2006) , or catchments in the Australian landscape (Angus  Webb et al. , 2007). In proteomics and genomics, where thousands of proteins or genes are detected at once, the need for data classification is even more crucial. To this aim, AutoClass@IJM  (Achcar, Camadro, & Mestivier, 2009) , a web server that utilizes AutoClass C, has made Bayesian classification more accessible (see for instance results from  (Elliott, Tanaka, Schwark, & Andrade, 2018; Léger, Garcia, Ounissi, Lelandais, & Camadro, 2015; Simpson et al. , 2011) ). Albeit its proven efficiency and versatility, AutoClass C is not easy to configure and run locally for the end user.
Overview The AutoClassWrapper library is a Python wrapper for AutoClass C. It aims to ease the usage of AutoClass C and offers: • Data preparation. User input data must be formatted as tab-separated values (TSV) files. They are quality checked with the pandas library  (McKinney, 2010)  and converted into suitable parameter files for AutoClass C. • Results extraction. AutoClass C output files are processed into more usable formats, such as clustered data (CDT) file for further visualization in Java Treeview  (Saldanha, 2004)  or TSV file for analysis with R, Python or any spreadsheet software. For all classes, descriptive statistics of numerical features are produced. An additional hierarchical clustering is performed on output classes and provides, through a dendrogram, a convenient way to assess proximity between classes.
AutoClassWrapper has been implemented with good practices in software development in mind  (Jiménez et al. , 2017; Taschuk & Wilson, 2017) : • version control repository on GitHub (https://github. com/pierrepo/autoclasswrapper), • open-source license (BSD-3-Clause), • continuous integration through tests, • and documentation (https://autoclasswrapper. readthedocs. io/en/latest/). AutoClassWrapper is available in the Python Package Index (PyPI). All versions of the software are archived in the Zenodo repository (https://doi. org/10. 5281/zenodo. 2527058) and in the Software Heritage archive (https://archive. softwareheritage. org/swh:1:dir: 330c16e8e3d999674f490135015d04de1f08e48a/).
Tonsil CD14 + cells do not contain a population of DC In vivo-generated mo-DCs express CD14  (Segura et al. , 2013b)  and efficiently induce CXCL13 secretion (Fig. 2 , F and G). To exclude the possibility that our tonsil macrophage preparations contain a population of CD14 + DC, we addressed the heterogeneity of tonsil CD14 + cells using single-cell RNA sequencing (RNA-seq) analysis. We purified tonsil macrophages (gated as HLA-DR + CD11c + CD14 + cells) and tonsil HLA-DR + CD11c + CD14 - cells (containing cDC populations) from the same sample (Fig. S2 A ), and analyzed single-cell transcriptomes using a dropletbased method enabling 39 mRNA counting  (Zheng et al. , 2017). To evaluate the heterogeneity of these cells, we merged the two datasets and performed unsupervised clustering based on a graph-based approach using the Seurat package  (Satija et al.
Clusters MAC2 and MAC3 expressed high levels of macrophage genes such as C1QA, CTSD, CD14, MAFB, and LMNA. Clusters APC1 and APC2 shared expression of genes expressed on progenitors or related to cDC development such as LTB, PRDM16, LST1, RUNX3, and CD164. In addition, clusters MAC3 and APC2 expressed cell cycle genes including STMN1, MKI67, TOP2A, and CDK1. Cluster APC3 expressed cDC1 genes such as CLEC9A, IRF8, C1orf54, RAB32, and CADM1. Cluster APC4 expressed cDC2 genes including CLEC10A, CD1C, FCER1A, and CD1E. Finally, cluster APC5 expressed DC activation genes such as CCR7, LAMP3, CCL19, MARCKSL1, and CD83. The complete list of top differentially expressed genes for this dataset is available in Table  S1. We then analyzed putative conserved genes between clusters, which may not be visible in the differential gene expression analysis.
We have previously evidenced a convergent transcriptional program between human cDC2 and in vivogenerated mo-DC  (Tang-Huau et al. , 2018). We interrogated the dataset to identify genes whose expression would be conserved between clusters MAC1 (potential monocyte-related population) and APC4 (putative cDC2 cluster) compared with all other clusters. The algorithm failed to identify genes that would be common to these two clusters without being also expressed by cluster MAC2 (Fig. S2 C ). By contrast, the same analysis for conserved genes between MAC1 and MAC2 identified genes highly expressed by all clusters from the "macrophage" sample (Fig. S2 D ), such as FTL, PSAP, FCER1G, SERPINA1, and CTSS. The complete gene lists for these heatmaps is available in Table  S1. Finally, to confirm the identity of these clusters, we analyzed signature scores in individual cells using transcriptomic gene signatures (Fig.