dataesr/scientific-paragraphs-categorization huggingface dataset:
Intel's Top-Down Analysis Methodology  [20]  classifies stalls into three major types, namely Front-end stalls, Speculation stalls, and Back-end stalls. During a cycle, if the BE is ready to execute a µOp but the FE is unable to queue it for execution, the stall is classified as a FE stall. A typical reason for FE stalls is instruction cache misses caused by large instruction footprint corresponding to a complex code base. Disk-based relational database engines are known to suffer from such stalls  [1]. Modern processors use speculative execution to improve instruction throughput. Conditional execution in programs, like if-else blocks get translated into branch instructions that decide control flow depending on predicates in the conditional statement. Before the processor has to execute a branch instruction, the predicate value has to be determined.
A. Hardware-software setup All experiments are conducted on a server running RHEL 7. 2, equipped with a 12-core Intel Xeon E5-2650L v3 CPU and 256GB RAM. We analyze four state-of-the-art sequence aligners, namely, BWA-MEM  [13]  and Bowtie2  [2] , Snap  [21] , and FSVA  [15]. We chose Bowtie2 and BWA-MEM as they are the most popular short-read aligners that use a BWT-based reference index. We chose Snap as a representative of a new breed of hashtable-based aligners that exploit the increasing read lengths to improve performance without sacrificing accuracy. We chose FSVA, as it is a state-of-the-art aligner built for cohort studies that explicitly trades off accuracy for fast single-threaded performance. As described in Section II, all these aligners use the seedand-extend technique to perform fast alignment of reads.
B. Experimental methodology We use both synthetic and real data set for evaluating each system. The synthetic dataset is generated by using wgsim. We generate two datasets with one million reads of length 150 bp each, one with the default rate of indels and one without any indels or substitutions. We use the two simulated datasets to perform a sensitivity analysis to the presence of indels. For the real dataset, we use a paired-end read (sample NA12878/09252015) obtained from the public Genome-In-A-Bottle (GIAB) dataset  [22]. We use Intel VTune for profiling each system. Before profiling, each aligner is run once to warm up the file system.
A. Indel-free dataset analysis Modern processors use an array of techniques like pipelining, out-of-order execution, speculation, and instruction prefetching to improve single-threaded performance. As a result, modern processors can retire multiple instructions per clock cycle as described in Section II. The efficiency of a software is determined by the metric Instructions Per Cycle (IPC), which determines the number of machine instructions executed and retired by the processor in each clock cycle. The Intel processor we use in this analysis can retire four instructions per cycle. Thus, in the ideal case, the IPC value of a sequence aligner should be four. I  shows the single-threaded execution time of aligners and Fig  2  shows the IPC values for the four aligners under the indel-free simulated dataset.
IPC analysis. Table Execution cycle breakdown. In order to further understand why observed IPC values are lower than the theoretical maximum, and explain difference in IPC across aligners and under different datasets, we need to analyze the processor activity on a finer microarchitectural level. Figure  3  shows the breakdown of execution cycles for each aligner into retiring and stalled for the indel-free datasets. We see that even in the best case, the processor is stalled in nearly 50% of cycles. This implies that the processor is substantially underutilized under all aligners and these stalls result in the low IPC values observed earlier. Stall-cycle breakdown. Given that a substantial fraction of cycles are stall cycles, the next step is to identify the root cause of these stall cycles.
B. Analysis of dataset with indels Having analyzed the microarchitectural behavior of aligners under the indel-free dataset, we now present our results using the with-indel dataset. Our goal is to understand if the presence of indels changes the microarchitectural behavior of aligners. IPC analysis. Table  I  shows the single-threaded execution time of aligners under the with-indel simulated dataset. Figure  7  shows the corresponding IPC values. Comparing the execution times between indel-free and with-indel datasets, we see that the execution time of all aligners increases in the presence of indels. This is expected given that the indels trigger expensive approximate alignment algorithms. However, comparing Figures  2, 7 , we see that the IPC value of aligners under dataset with indels is higher than the IPC value without errors.
Execution cycle breakdown. Figure  8  shows the breakdown of execution cycles for each aligner into retiring and stalled for the with-indel datasets. Similar to the indel-free dataset (Figure  3 ), we see that even in the best case, the processor is still stalled in nearly 50% of cycles. However, across all aligners, the processor retires more instructions when the dataset has indels compared to a dataset without indels although. This directly translates into corresponding difference in IPC observed earlier between the two datasets. Stall cycle breakdown. Figure  9  shows the stall cycle breakdown for each aligner under the with-indel dataset. Comparing this with the indel-free case (Figure  4 ), we can make two observations. First, under Bowtie2, BWA-MEM, and FSVA, the dominating source of stalls is still the Back-end which Comparing this with the indel-free case (Figure  5 ), we see that BWA-MEM and Bowtie2 behave similarly at the microarchitectural level irrespective of the presence or absence of indels.
However, with FSVA, memory stalls are no longer the dominating source in the presence of indels as core stalls account for 60% of stalls. This indicates the presence of different code paths in FSVA for dealing with indel-free and indel-based cases, and the existence of complex branching logic in the extension stage of both these aligners that is activated only under datasets with indels. Memory stalls analysis. Given that memory stalls still account for 40-76% across aligners, Figure  11  breaks down memory stalls across various cache levels and DRAM under the with-indel dataset. Comparing Figures  6, 11 , we see that under BWA-MEM and FSVA, long-latency DRAM stalls continue to dominate and contribute to over 80% of all memory stalls in both indel-free and with-indel datasets. Insights. While processor utilization improves in the presence of indels across all aligners, the processor still spends majority of its cycles in the stalled state.
C. GIAB dataset analysis So far, we have presented our analysis based on the simulated datasets. The microarchitectural behavior of aligners under the GIAB dataset is very similar to the simulated, withindel dataset. Table  I  shows the single-threaded execution time of aligners under the GIAB dataset. Figures 12, 13  show the IPC and execution cycle breakdown. Comparing this with Figure  8 , we see similar trends between the with-indel simulated dataset and the GIAB dataset as the processor is stalled in 50-70% of execution cycles. Figure  14  breaks down the stall cycles into various components. Similar to the simulated dataset (Figure  8 ), back-end stalls account for 60-70% of stall cycles under Bowtie2, BWA-MEM, and FSVA. Speculation stalls are the dominating source of stall cycles under Snap.
The third is the extension stage where the entire read is aligned with each candidate location to identify the best match. Once a read has been processed by all the three stages, the aligner writes the alignment information to the file and moves to the next read. The analysis results we have presented so far are from an inter-stage analysis that spans across all stages. In this section, we present intra-stage analysis where we explore processor utilization within each stage to identify which stages account for stall cycles so that we can answer the aforementioned questions. In order to perform the intra-stage analysis, we modified FSVA so that data is processed in a stage-at-a-time fashion. We chose FSVA as it is was the fastest aligner in our study and has a simpler code base due to its focus on single-threaded performance.
By using a stage-at-a-time execution approach, staged-FSVA makes it possible for us to accurately measure and profile each stage independently. Table  II  shows a breakdown of execution time of each stage of staged-FSVA under the with-indel simulated dataset. As expected, the Smith-Waterman extension stage dominates overall execution time. Figure  17  shows the IPC values for each phase of staged-FSVA. Whlie the filtration and extension stages have IPC values of 2. 5 and 2. 9, the seeding and hashtable lookup stage has only an IPC value of 0. 5. This highlights that the main bottleneck leading to low IPC count, and hence poor processor utilization, is the first stage.
VII. CONCLUSION Sequence alignment is the first stage of genomic data analysis and a very well-studied problem. Decades of research on scalable, high-performance approximate string matching algorithms have led to the development of fast sequence aligners that can map thousands of reads per second. However, there is no work that analyzes the efficiency of sequence aligners with respect to processor utilization. In this study, we presented the first microarchitectural analysis of four state-of-the-art aligners. Our analysis on simulated datasets as well GIAB data revealed that all aligners result in substantial underutilization as the processor remains stalled for 50%-70% of execution cycles. We identified back-end memory stalls and speculation stalls as leading sources of inefficiency. To understand the source of these stalls, we also presented a stage-by-stage analysis which mapped memory stalls to the seeding stage and speculation stalls to the filtration and extension stages.
Given the complexity of the survival task that we target to demonstrate, it is considerably difficult to choose the right kinds and number of attributes to be encoded in the model. Malmo, exploiting the power of Minecraft environment, precisely provides such great convenience to study our model of generic loops. Here, since our goal is to explain the dynamics of emergence of the behavior using and organizing the loops defined in the model presented above, we use only a specific set of Malmo features that are adapted according to the task and the model. We have designed on the top of Malmo a minimal software layer to accommodate our adaptations concerning the interoceptive and exteroceptive attributes relevant to the survival task. Particularly, Malmo provides a set of attributes representing the vital characteristics of the agent.
We have built on them more precise variables relevant to the task together with their functional dynamics, as a part of the software layer. Similarly, the adaptations related to the agent's vision and the sensori-motor responses can be conveniently implemented using the related features of Malmo. These attributes in conjunction with our adaptations concisely explain the generic dynamics in the loops as a result of which several behaviors emerge. Furthermore, it is interesting to observe that Malmo invariantly supports demonstrating these different behaviors with no or minimal changes to itself but only from the changes in the state of the agent or that of the environment. In the rest of this section, we explain the attributes of Malmo that we have used in the context of the survival task. In the subsequent section, we describe the additional software layer with the adaptations that also demonstrates the embodiment of the agent.
Participants Whilst the visually impaired population tends to be mainly over 60 years of age, the population group is actually varied both in terms of their age range and the types of visual deficiency that affects them  (World Health Organization, 2012). For our studies, we use the World Health Organisation  (WHO, 2004)  categorisation with a split between categories 1 to 3 (partially sighted) and categories 4 and 5 (blind). For the data collection with visually impaired people, 17 adults (7 females; M=51 years-old; SD=12) were recruited from the database set up and run by Streetlab. Thirteen of them fell into WHO categories 1 to 3 (partially sighted) and 4 fell into WHO categories 4 and 5 (blind). For the older adults group, 20 participants (10 females; M=70. 63 years-old; SD=8. 61) were recruited among volunteers (relatives and acquaintances of colleagues and friends) and members of a local senior association.
Metaphoric gestures, which are meaningful to the user because they exploit primary metaphors to connect gestures to abstract interactive content, should be preferred over semaphoric (symbolic) gestures  (Hurtienne et al. , 2010; Saffer, 2008). ▪ Feedback on the system status. As this was a data collection aimed at building the dataset to be used for training the recognition algorithms, no feedback was built into the system. Despite this, observations and participants' comments highlighted the need for timely and useful feedback of mid-air gesture recognition (currently the feedback was given by the experimenter). ▪ General usefulness for visually impaired users. Doubts were raised about the usefulness of mid-air gesture interaction for visually impaired people. For instance, participants said that mid-air gestures are "more adapted to the elderly than visually impaired", and "visually impaired people are used to touching things, so mid-air gestures are not natural", "more useful for tablets or the television".
CONCLUSIONS This paper reported on two early user studies aimed at investigating issues concerning the design of multimodal interaction -based on speech commands and mid-air gestures -with mobile technology specifically designed for visually impaired and elderly people. This type of multimodal interaction, which enables a natural and efficient way of humancomputer interaction with mobile devices, is investigated in the ECOMODE project, which aims at exploiting the biological-inspired technique of EDC of audio-visual information. Seventeen visually impaired people and twenty older adults were involved in our study, which consisted of collecting and analysing a set of audiovisual data, which were recordings of our users when performing a sequence of seven multimodal commands. The data was collected by means of a special camera, a prototype developed inside the ECOMODE project.
In this paper, we propose a Domain Specific Language (DSL), and we focus on the AGGIR (Autonomie Grontologie Groupes Iso-Ressources) grid model, in order to exploit the variety of interaction capabilities according to the performanceto current activities, users, and context over the time domain. Our aim is providing an analyis tool regarding the coherent behaviour of elderly/handicapped people within a home environment by means of data recovered from sensors using the iCASA simulator. For the DSL validation, we particularly focus on three of the AGGIR variables: dressing, hygiene and transfers; by evaluating their testbility in many scenarios, especially the abnormal ones, which contain readings representing the occurrence of accidents or unexpected behavior of the elderly, in order to see the ability of the system to understand the obtained records correctly and thus generate the appropriate event information.
INTRODUCTION Due to the increase of aging population and the necessity to avoid expensive hospital-based health care  (Zhang et al. , 2005)  for this sector, reducing medical costs and improving quality of care service  (Varshney, 2003)  have become in recent years a need for new care delivery mechanisms ans structures  (Boulos et al. , 2009). The present article aims to achieve the monitoring of a person within a smart home environment to verify and to detect possible anomalies related to his coherent behaviour. To achieve such a goal, we will identify the activities performed by the inhabitants over a certain period of time, by means of collection and analysis of data obtained from sensors located in the sourroundings of the aforementioned environment. In order to address such a task, we define a Domain Specific Language (DSL) which will permit to perform the analysis of the collected data.
, 2005; Consel, 2004; Van Deursen et al. , 2000). The language must be able to describe the data that one wishes to recover from the various sensors present in a house and the operations related to them. We propose to represent the DSL by means of a graphical user interface (GUI), in order to describe complex events. In this context, a complex event is considered as an activity performed by an inhabitant that is detected by several sensors at the same time. We consider that a graphical DSL would be easier to handle than a textual language, since the the future user might not be necessarily a person who is acknowledged in the programming field. We propose to represent activities performed by the elderly or handicapped people within a home environment, for this reason it is imperative to be aware when such activity takes place, as well as if there exists repetition or periodicity during the interval of its performance.
Sensors With regard to identification of activities of daily living (ADL) by means of several sensors for providing non intrusive monitoring, we propose a group of sensors that can describe such activities. Those ones are enlisted in Table  2 , where some examples of their use are proposed. Additionally data attributes and data types for each sensor are indicated. Additionaly, relevant data for each performed task by the inhabitants is considered, in order to obtain information to achieve the identification of the AGGIR constants after every activity has been carried out to completion. The above-mentioned data is represented on Table 3. Such data collection is necessary to keep hisof all the activities performed by the inhabitants, by means of a log file which will be able to precise whether an activity begins or ends, helping to manage which activity has begun, or which activity has already ended; as well to specify if an activity has already begun, while in the meantime, there is another one that occurs at the same time and/or that has not been finished yet.
The mechanism to measure the ability of the personto wake up after falling on the ground is not covered in this approach. • To verify if the dressing variable is achieved, dressing events like approching the wardrobe must be encountered at least twice a day. Moreover, the source code that analyzes the records and generates the events is written in Python and run on the simulation host. It is written using a function-oriented approach, this makes the Original code scalable and future additions can be made to calculate the rest variables in a facile way.
The inclusion of introgressive processes in evolutionary studies induces a less constrained view of evolution. Network-based methods (like large-scale similarity networks) allow to include in comparative genomics all extrachromosomic carriers (like viruses, the most abundant biological entities on the planet) with their cellular hosts. The integration of several levels of biological organization (genes, genomes, communities, environments) enables more comprehensive analyses of gene sharing and improved sequence-based classifications. However, the algorithmic tools for the analysis of such networks are usually restricted to people with high programming skills. We present an integrated suite of software tools named MultiTwin, aimed at the construction, structuring, and analysis of multipartite graphs for evolutionary biology.
In the example of a gene family-genome bipartite graph these points may be a bridging gene family or set of gene families that are shared by otherwise very different genomes, indicative of long-distance gene sharing  (Corel et al. 2018). Furthermore, the MultiTwin suite can generate a bipartite gene family-genome graph directly from genomic or proteome sequence data (i. e. , either from sequences themselves or the output file of a BLAST allagainst-all run on the set of sequences) to summarize all gene sharing between that set of genomes.
Analysis of k-Partite Graphs MultiTwin includes a program named detect_twins. py for the detection of exclusively shared nodes, that is, nodes having exactly the same neighbors, and of their support (i. e. , their common neighborhood). It also includes a dedicated tool to construct gene families (familydetector). Finally, it features a module (description. py) to annotate the content of a k-partite graph (and of its possible intermediate modifications). For instance, figure  1  represents a bipartite graph that is subjected to three successive modifications: intermediate modifications are construction of gene families (level 1) and detection of twins (level 2).
File Formats and Types All files generically follow the same syntax X TAB Y. MultiTwin works with the following basic files. • Node type files where X is a node ID and Y is the node type (e. g. , type 1 corresponding to genes and type 2 to genomes). Node type files can be omitted for unipartite graphs, and also for bipartite graphs, provided that the first column of the edge file only contains type 1 nodes, and the second column type 2 nodes. • Edge files where X denotes the head and Y the tail of an edge. • Community files where X is a node ID and Y is a community ID. These files encode overlapping and nonoverlapping clusterings (depending on whether node IDs are repeated or not). Community files are generated by MultiTwin but can also be supplied by the user. For example, the decomposition of the graph into connected components can be encoded as a community file.
Clusters can be any kind of node subsets: groups of gene families or genomes, nodes forming a connected component, communities returned by an external clustering algorithm, and so on. • Trail files, where X refers to the node ID in the root graph, Y to the node ID in the compressed graph. These files start with a two-line header recalling the operation that has produced the compressed graph. Trail files allow to track consistently successive modifications of multipartite graphs and are therefore exclusively generated by the MultiTwin suite. Only the annotation file, provided by the user, and which contains the biological information has a different format. It consists of a tab-separated file, whose first row contains the attribute names corresponding to the column below, and whose remaining rows start with the identifier used in the root graph, like in the following example: UniqID Species Project ID Pathogen 57955 Rhizobium leguminosarum PRJNA57955 No.
Implementation and Availability The implementation of the framework was carried out in Python (version 3. 5) with some additional original code in Cþþ. The Python code includes efficient implementations of graph algorithms from the igraph package (Cs ardi and Nepusz 2006), that can moreover be accessed through the python-igraph wrapper. The source code available at https://github. com/TeamAIRE/ MultiTwin, last accessed October 6, 2018; accepts different kinds of inputs, depending on the user's objectives. A detailed file with installation and usage information is provided. A user-friendly graphical interface is available for the main scripts of the MultiTwin suite. The data used in the application is also included as supplementary material online with a dedicated guide file that allows to replicate our analysis.