dataesr/scientific-paragraphs-categorization huggingface dataset:
The following combined criteria are used: QualByDepth (QD) >2, FisherStrand (FS) <60, RMSMappingQuality (MQ) >40, StrandOdds-Ratio (SOR) <10, ReadPosRankSum > À8. 0, MQRankSum > À12. 5, and QUAL >30. To ensure that SNPs are accurately identified, SNPs within a 35-bp sequence are also filtered. Genotype filtering is performed depend-ing on the availability of the parental data and information on dominant or recessive alleles. Moreover, mutation sites that satisfy the following conditions are also eliminated: homozygous and identical mutations in two mixed pools; homozygous and identical mutations in the parents; heterozygous mutations in recessive parents or mixed pools; and mutations in recessive mixed pools that are homozygous and different from those in the recessive parent. The filtered VCF file is converted to a matrix format using a self-written bash script for subsequent interval mapping.
The current Triti-Map pipeline supports the use of the allele frequency difference (DSNP index) method  (Takagi et al. , 2013b)  for mapping candidate intervals. The QTLseqr  (Mansfeld and Grumet, 2018)  package is used to calculate the DSNP index and identify the trait-associated interval. The results are filtered and visualized using a self-written R script.
De novo assembly and bulk-specific sequence screening and annotation The pre-processed DNA-seq data are assembled using ABySS (version 2. 0. 2)  (Jackman et al. , 2017) , with k = 90. The transcripts detected by RNA-seq are assembled using the default parameters of rnaSPAdes (version 3. 15. 0) (Bushmanova et al. , 2019). Assembled sequences longer than 500 bp are retained and mapped to the reference genome using the default parameters of bwa-mem2 (DNA-seq) and minimap2 -ax splice (RNA-seq)  (Li, 2018). The assembled sequences of the two mixed pools that are not aligned or partially aligned (i. e. , reads containing soft-clipped fragments or with an alternative alignment with cigar strings SA:Z and XA:Z) to the reference genome are selected for subsequent analysis. The screening process involves the SeqKit  (Shen et al.
, 2016)  and BEDOPS (version 2. 4. 36) (Neph et al. , 2012)  programs, as well as a self-written bash script. Target trait-related bulk-specific sequences are obtained via a reciprocal Basic Local Alignment Search Tool (BLAST) analysis of sequences from two bulks. To further narrow down the candidate sequences, all regions of Triticeae genomes colinear with the candidate intervals identified using the interval mapping module are identified. Bulk-specific sequences highly similar to these regions are considered to be candidate sequences (BLAST default parameters). The candidate sequences are functionally annotated using the EBI HMMER3 hmmscan API. Their homologous sequences and information on their functions in plants are retrieved from the Ensembl Plants database using the EBI BLAST API. Combining the above information, Triti-Map will generate a table of functional annotations and homologous sequence information for the new candidate sequences and positional information for comparison with the reference genome.
Triticeae species data collection and processing Genome sequences and annotation details are obtained from the Ensembl database  (Yates et al. , 2020)  for the following six Triticeae species: H. vulgare, Ae. tauschii, T. urartu, T. dicoccoides, T. turgidum, and T. aestivum. Information is also retrieved for 10 hexaploid wheat genomes  (Walkowiak et al. , 2020). Epigenomic data from Triticeae species are compiled, including different histone modification ChIP-seq and DNase I hypersensitive site (DHS) data (Figure  2A ; Supplemental Table  1 ). In addition, model-based analysis of ChIP-seq (MACS)  (Zhang et al. , 2008)  is used to identify read-enriched regions, and MotifScan  (Sun et al. , 2018)  is used to locate transcription factor-binding motifs. Or-thoFinder  (Emms and Kelly, 2019 ) is used to identify orthologous genes across Triticeae species.
Availability of the Triti-Map package and web-based interface The Triti-Map package was developed using Snakemake  (Koster and Rahmann, 2012)  and Conda. The package and manual are available online (https://github. com/fei0810/Triti-Map). Triti-Map can be installed from Bioconda  (Gr€ uning et al. , 2018)  and Docker. The web-based Triti-Map interface is also accessible (http://bioinfo. cemps. ac. cn/tritimap).
ACKNOWLEDGMENTS We thank  Huang Tao  for his help in maintaining the high-performance computing server. We thank  Zhougeng Xu  for insightful communications. We are grateful to  Martin Mascher  for facilitating access to 10+ Wheat Genomes data. We thank  Robbie Lewis , MSc, from  Liwen Bianji (Edanz)  (www. liwenbianji. cn/)for editing a draft of this manuscript. The authors declare that they have no competing interests.
Data access The package and manual are available online (https://github. com/fei0810/ Triti-Map). Triti-Map can be installed from Bioconda and Docker. The web-based Triti-Map interface is also accessible (http://bioinfo. cemps. ac. cn/tritimap). The ChIP-seq data have been deposited in the Sequence Read Archive (SRA) and assigned the identifier accession PRJNA725543 (https:// www. ncbi. nlm. nih. gov/bioproject/PRJNA725543).
, 2009; E. M. Meyers et al. , 2015; Nirenberg & Latham, 2003) , such as whether there is a small subset of neurons that contain all the information present in a larger population (E. M. Meyers et al. , 2008a Meyers et al. , , 2012) )  and whether information is coded by patterns of activity that change in time  (King & Dehaene, 2014; Meyers, 2018; Meyers et al. , 2008a). Despite the advantages neural decoding has as a data analysis method, the code needed to run a decoding analysis can be complex which can present a barrier to using the method. To address this difficulty, several software packages exist that make it easier to run these analyses including packages in Python  (Glaser et al. , 2020; Hanke et al. , 2009)  and MATLAB  (Hebart et al. , 2015; Oosterhof et al. , 2016; Peng et al. , 2020).
In previous work we have also tried to address this issue by creating a MATLAB toolbox called the Neural Decoding Toolbox  (Meyers, 2013). In this paper, we introduce a new neural decoding package written in R (R Core Team, 2021), called NeuroDecodeR. The design of the NeuroDecodeR is based on the design of the MALTAB Neural Decoding Toolbox, but it extends its functionality several ways. In particular, the NeuroDecodeR includes the ability to easily add new measures for quantifying decoding accuracy, a system to manage results, and the ability to run the code in parallel which greatly speeds up the time it takes to run an analysis. Additionally, using the R programming language has several advantages including that R is free/open source, and that there is a large data analysis ecosystem for creating reproducible data analyses.
In the following paper, we describe the design of the NeuroDecodeR package, the data format that is used by the package, and we give an example of how the package can be used by reproducing results from  Meyers et al (2015). We hope this package will make it easier for neuroscientists to extract insights from the data they collect, and will help introduce neural decoding analyses to the larger Statistics/Data Science community that uses R to analyze data.
Installing the NeuroDecodeR package The NeuroDecodeR package has been published on the comprehensive R archive (CRAN). Like all R packages, the NeuroDecodeR package must be installed before it can be used for the first time. To install the package, use the command: install. packages("NeuroDecodeR"). Once the package is installed, any time you would like to use it you can load it into memory using: library(NeuroDecodeR). Online documentation for the NeuroDecodeR package is available at https://emeyers. github. io/NeuroDecodeR/. The development version of the package is available on GitHub at https://github. com/emeyers/NeuroDecodeR.
Design of the NeuroDecodeR package The NeuroDecodeR package is designed around five abstract object types which allows researchers to easily experiment with a range of different decoding analyses. The five object types are: 1. Datasources (ds): These objects create training and test splits of the data. 2. Feature preprocessors (fp): These objects extract statistics from the training set, and then apply transformations to the training and test set. These transformations are typically used to either improve the decoding accuracy, or to assess how information is coded in neural activity. 3. Classifiers (cl): These objects learn the relationship between neural activity and experimental conditions on the training set of data, and then make predictions on the test set of data. 4. Result metrics (rm): These objects compare the predictions made by the classifier on the test set of data to the experimental conditions that were actually present and then create metrics that indicate how accurate the predictions were.
The NeuroDecodeR package comes with one or more implementations of each of these object types, as listed in Table  1. A description of how to use these objects to run a decoding analysis is shown in the Results section below. The advantage of this modular design is that it allows researchers to easily try out different analyses to gain additional insights and to make sure the results are robust to particular analysis choices. For example, as described below in the Results section, one can use the ds_generalization datasource instead of the ds_basic datasource to run a generalization analysis which can assess whether there is abstract information in the neural data. Each of these object types are defined by an interface which specifies exactly which methods each object must have to work with the other object types in the package.
This design allows users to add new implementations of the objects to their analysis. For example, a researcher could create a new classifier by implementing an S3 object that has a get_predictions() method. 1 More information on how to implement the methods needed to create new NeuroDecodeR objects is available on the NeuroDecodeR's documentation: https://emeyers. github. io/NeuroDecodeR/articles/NDR_object_specification. html. 1 Experimenting with different classification algorithms is useful for gaining insight into the 'neural code' and for assessing the maximum amount of information that could be extracted by a sequence of downstream areas  (Glaser et al. , 2020; E. M. Meyers et al. , 2015). Datasources (ds): • ds_basic: creates training and test splits of the data, including the ability to create pseudopopulations.
Cross-validators (cv): • cv_standard: Takes ds, fp, cl, and rm objects, and using the run_decoding() function, a crossvalidation loop is run several times to create the decoding results. Table  1. A list of implementations NeuroDecodeR objects that come with the NeuroDecodeR package. The package also includes a number of additional functions that are useful for processing data, plotting, and saving/loading results. For more details on these objects, see Supplemental Table  1 , and the online documentation at: https://emeyers. github. io/NeuroDecodeR/reference/index. html.
Raster format In order to use the NeuroDecodeR package, neural data must be put into a particular format called "raster format". In this format, data from each recording site is in a separate "raster data" file. The data in each of these raster data files consists of a data frame where each row corresponds to one experimental trial, and each column must start with the prefix site_info. , labels. , or time. Columns that start with the prefix site_info. contain meta-information about the recording site. Columns that start with the prefix labels. contain information about which experimental conditions were present. Columns that start with the prefix time. contain the neural activity that occurred at a particular point in time. To illustrate the data formats NeuroDecodeR package uses, and how to run a decoding analyses, we will use data from the "Friewald Tsao Face Views AM data set"  (Freiwald & Tsao, 2010).
This data set consists of recordings made from neurons in the macaque anterior medial face patch (AM) while monkeys viewed a random sequence of images where each image was presented for 200 ms with a 200 ms inter-stimulus interval. The images shown consisted of faces from 25 different people taken from 8 different head orientations 2. For readers who are interested in replicating the analyses described below, a zip file that contains a directory with raster data from this experiment can be downloaded from http://www. readout. info/downloads/datasets/freiwald-tsao-face-views-am-dataset/. When this data archive is unzipped, a directory will be created called Freiwald_Tsao_faceviews_AM_data/ that has 193 files of data in raster format that we will use in the analyses. Figure  1A  shows data from one neuron that is in raster format.
Since the recordings are neuronal spiking activity, each data value in these "time" columns is either a 1 indicating a neuron produced an action potential or a 0 indicating that it did not. As described below, we can visualize raster format data using the plot(raster_data) function, which will produce plots such as the one shown in Figure  1B. When analyzing data from a new experiment, one can put data into raster format by saving data in comma separated value (csv) files with the appropriate column names (i. e. , columns names that start with site_info. , labels. and time. ). The data can then later be loaded in raster format using the read_raster_data() function. Alternatively, one can save them in the MATLAB Neural Decoding Toolbox raster format (http://www. readout. info/toolbox-design/data-formats/raster-format/) and then convert the files into R using the convert_matlab_raster_data() function.
Binned format Once one has created a directory that has data files from each recording site in raster format, one can convert this data to "binned format" using the create_binned_data() function. After this conversion is done, the rest of decoding process relies only on data in binned format. Data in "binned format" is similar to data in raster format in that it contains the same site_info. , labels. and time. columns. ; however, the binned data time. columns contain data at a coarser temporal resolution that is created by averaging activity in sliding time windows. For example, the Friewald Tsao Face Views raster data is recorded at millisecond resolution, as indicated by the fact that the time bins are successive numbers; i. e. , time. 1_2, time. 2_3, time. 3_4, etc. However, as described in the Results section, we can use the create_binned_data() to create averaged firing rates in 30 ms bins sampled every 10 ms, which will give us time bins columns with values time.
Viewing raster data As mentioned above, to illustrate how to use the NeuroDecodeR package we will analyze the "Friewald Tsao Face Views AM data set" which consists of 193 files in raster format that are stored in a directory called Freiwald_Tsao_faceviews_AM_data/. To begin we will load one of these raster format files using the read_raster_data() function, and then we can plot the data using the plot() function as follows: raster_dir_name <-"Freiwald_Tsao_faceviews_AM_data" raster_data <-read_raster_data(file. path(raster_dir_name, "raster_data_bert_am_site021. rda")) plot(raster_data) The results from visualizing the raster data for this neuron are shown in Figure  1B. In the plot, the x-axis corresponds to time from the stimulus onset, y-axis corresponds to different experimental trials, and black tick marks on the plot corresponds to the time when action potentials occurred.
Assessing how many recording sites and cross-validation splits to use Before starting to run a decoding analysis, it is useful to assess how many trials were collected from each recording site for each stimulus that was shown; for example, for neuron with siteID 7, how many trials were recorded when the image "left profile 3" was shown, etc. By examining this information across all the sites that were recorded, one can assess how many cross-validations splits to use, and whether specific sites should be excluded from further analyses because not enough trials were recorded from a given site. This is particularly important when creating pseudo-populations from experiments where data from different sites were recorded in different experimental sessions, since it is likely that sites that were recorded in different sessions will have different numbers of trials for each stimulus.
Running the decoding analysis Now that we have binned the data, and we have decided to use 3 cross-validation splits, we are ready to run the decoding analysis. To do this, we will first create a vector with the 25 strings that contain the names of label level for trials when left profile images were shown. We can do this by creating a vector of strings to restrict our decoding analysis to only decode trials when the left profile images were shown. left_profile_levels <-paste("left profile", 1:25) We can then run a decoding analysis by creating each of the 5 object types described in the Method section. For our first analysis we will use a: 1. ds_basic data source to create pseudo-populations of data. The arguments we pass to this constructor are: a) the name of the binned data file; b) the variable we want to decode (e.
5. cv_standard cross-validator to run the full decoding analysis. The arguments we pass to this constructor are: a) the data source; b) the classifier; c) the feature pre-processor; d) the result metrics; and e) a number specifying how many resample runs to use. We set up these decoding objects using the code below: We can then run the decoding analysis using the cross-validators run_decoding() method as shown below where we can store the results from this analysis in a list that we usually name DECODING_RESULTS: DECODING_RESULTS <-run_decoding(cv) The run_decoding() function runs the decoding process in parallel, where the number of parallel cores can be specified by the optional num_parallel_cores argument to the cv_standard object (by default runs the code in parallel using half the cores that are available on the computer used for running the analysis)  7.
Plotting the results The DECODING_RESULTS object created by running the run_decoding() function is a list that contains result metric objects which now hold the compiled results. Additionally, the DECODING_RESULTS object contains a list called cross_validation_parameters which stores the parameters that were used to generate the results. To see this for the DECODING_RESULTS object we created above, we can print out the names of the values stored in the DECODING_RESULTS object using: > names(DECODING_RESULTS) [1] "rm_main_results" "rm_confusion_matrix" "cross_validation_paramaters" If we examine the DECODING_RESULTS$cross_validation_parameters list, we see it contains the objects used in the decoding analysis including ds, fp, cl, and rm objects, along with information about the analyses stored in the parameter_df data frame.
The rm_confusion_matrix result metric plot() function allows one to view a sequence of confusion matrices for each time period that was decoded. Because we binned the data with a relatively small sampling interval of 10 ms, plotting a sequence of confusion matrices for all decoded time bins will be rather cluttered, so instead we will just plot the confusion matrix that starts around 200 ms after stimulus onset, which we can do by setting the argument start_time_to_plot = 200: plot(DECODING_RESULTS$rm_confusion_matrix, plot_only_one_train_time = 206) The results are shown in Figure  4. The y-axis on the plot shows the true class, and the x-axis on the plot shows the predicted class, and consequently diagonal elements on the plot are correct predictions. From looking at Figure  4 , we see that some classes (i.
e. , anterior-medial face patch contains a representation of face identity that is invariant to the orientation of an individual's head  (Meyers et al. , 2015). Running this generalization analysis is very similar to running the basic decoding analysis we did above, however, we will use the ds_generalization data source rather than the ds_basic data source. The data, and all other NeuroDecodeR objects in this analysis will be the same as we used previously, which illustrates how the modular nature of the object in the NeuroDecodeR package allows one to easily run a range of analyses. To create the ds_generalization data source, we will first create a vector of 25 strings that list all the right profile image names in the same order as the vector of left profile image names that we created previously.
This can be done using: right_profile_levels <-paste("right profile", 1:25) We can then create the ds_generalization datasource by specifying the same binned_file_name, label_to_decode, num_cv_splits, and site_IDs_to_use 8  arguments as was done with the ds_basic, along with setting the train_label_levels to be the left_profile_levels, and the test_label_levels to be the right_profile_levels. Thus, the code for creating the ds_generalization is: ds <-ds_generalization(binned_file_name, labels = "orient_person_combo", num_cv_splits = 3, train_label_levels = left_profile_levels, test_label_levels = right_profile_levels, site_IDs_to_use = sites_to_use) Now that the generalization data source has been created, we can create the other NeuroDecodeR objects, run the analysis, and save the results as was done before.
Piping together NeuroDecodeR objects A popular way to write data analysis code in R is to use the pipe operator to string together a sequence of data analysis functions. The NeuroDecodeR package also supports the pipe operator to create a sequence of functions that are needed to run a decoding analysis. This can be done by: 1. Starting with a binned data file name 2. piping it to a data source 3. piping together feature-preprocessors, a classifier, and result metrics 4. piping this to a cross-validator. The code below illustrates how to run the same basic analysis as our first analysis above using the pipe operator. For the sake of novelty, we will decode the right profile images, and we plot the results from all the analyses we have run (see supplemental Figure  1 ). result_names <-c(result_names, "Right profile face decoding") plot_main_results(results_dir_name = "results", result_names) 9 Spoiler, decoding accuracy on the frontal images is higher, and there is less invariance generalizing from the frontal images to the profile images.
Discussion In this paper, we introduced the NeuroDecodeR package, described the design and data formats used by the package, and gave examples of how to run a basic decoding and generalization analysis. We also described the benefits of using the package, including the fact that the modular design of the package makes it easy to run a range of different decoding analyses, the decoding code is parallelized which speeds up the run time of analyses, and a system that makes it easy to save and manage decoding results. Additionally, using the R programming language to run decoding analyses has several benefits including that it is a free/open source language, and that R has a strong ecosystem for creating reproducible analyses. In particular, we highly recommend that users of the NeuroDecodeR package take advantage of these reproducible features in R by creating R Markdown documents that contain the code used for each analysis so that it is easy to recreate any analysis run 10.