Find research datasets worth reusing
Search datasets from major research repositories and use ShareScore to quickly assess how well each record supports discovery, access, and reuse.
5
datasets available to search
ShareScore release 0.9.0
Dataset results
5 results for “real faults”
Dataset of Real Faults in Deep Learning Systems
<p>This is a replication package for the "Taxonomy of Real Faults in Deep Learning Systems" paper.</p> <p>The dataset contains information on all the issues and real faults gathered in the course of the study.</p> <p>The dataset consists of three main folders: Manual_Labelling, Interviews and Survey.</p> <p>Manual_Labelling</p> <p>In this folder we have placed all the files associated with our manual labelling process. It is divided in 3 subfolders: SO_init, GitHub_init and Analysed_Artifacts.</p> <p>GitHub_init</p> <p>The GitHub mining process is explained in detail in Section 3.1.1 of the paper. The list of initially mined GitHub projects for each framework is presented in the file {frameworkname}_init.csv. Each line in the file provides project name, the link to the project and its general information such as number of commits, issues, stars and etc. As part of our procedure, we removed projects that do not represent real software systems. For such projects we provide an explanation on why it should be excluded in the column "Comment". The files {frameworkname}_after_init_removal.csv present the list of remaining projects after the exclusion of such systems. The files {frameworkname}_top_100.csv list the top 100 projects we selected for our final analysis.</p> <p>As explained in Section 3.1.1, to identify relevant commits and issues we used a vocabulary of related terms. The complete list of 11,968 stemmed words is presented in the file vocabulary_init.csv. The final list of 105 relevant words obtained by the exclusion of the words that appear less than 10 times and the further manual analysis is provided in the file vocabulary_final.csv.</p> <p>SO_init</p> <p>The extraction procedure from StackOverflow is explained in detail in Section 3.1.2 of the paper. In the file query.rtf we provide the code of the query we have used to extract discussions related to each of the analysed frameworks (Keras, Torch, Tensorflow) from StackOverflow. As a result, we got a csv file that lists discussions for each of the frameworks (files keras.csv, torch.csv and tensorflow.csv).</p> <p>Analysed_Artifacts</p> <p>Our manual analysis was conducted in 6 rounds (Table 1 in the paper). We provide information about each round in a separate csv file round_{roundnumber}.csv. In each file we provide the following information: (1) <strong>Entity Type</strong> - whether it is a StackOverflow or GitHub artifact and which framework it corresponds to; (2) <strong>Link</strong> to the artifact; (3) <strong>Number of Evaluators</strong> - how many evaluators were assigned to this artifact; (4) <strong>Conflict</strong> - whether there was a conflict between evaluators when assigning tag to this artifact, has a value 0 for no and 1 for yes; (5) <strong>Evaluator1..4</strong> and <strong>Tag1..4</strong> - the ID of each evaluator and the tag provided by each of the assigned evaluators; (6) <strong>Final Tag</strong> - final tag assigned to the artifact; (7) <strong>Taxonomy Tag</strong> - the tag in the final taxonomy;</p> <p>The detailed information on the statistics of each round can be found in file stats.xlsx.</p> <p>Interviews</p> <p>The background information about our interview participants is presented in the file interview_participant_info.xlsx. The interview guide we used to conduct the semi-structured interviews is in the file interview_guide.docx. In the subfolder "Transcriptions" we provide transcribed versions of all 20 interviews.</p> <p>We provide the details of open coding process for the interviews in the file interview_open_coding.xlsx. Each row corresponds to a part of the interview text to which at least one of the evaluators has assigned a tag. Therefore, each row contains the following information: (1) <strong>Interview Num</strong> - the interview number; (2) <strong>Evaluator 1</strong> - tag provided by the first evaluator; (3) <strong>Evaluator 2</strong> - tag provided by the second evaluator; (4) <strong>Moderator Tag</strong> - tag assigned by the moderator; (5) <strong>Tag</strong> - the final taxonomy tag; (6) <strong>Status</strong> - whether this tag has been added to the final taxonomy or not ("A" for yes and "R" for no).</p> <p>In the file Interview_Tags.xlsx we provide aggregated information about the tags obtained from interviews. The column "Number" shows the number of times the tag was extracted from the interviews. Similarly to the previous file, the column "Status" shows whether the tag became part of the final taxonomy or not.</p> <p>Survey</p> <p>We provide the survey form we have used for our validation study in the file survey_form.pdf. The file with the information about participants and their answers to the survey questions are in the file participant_info_and_responses.xlsx. The percentages reported in Table 2 in the paper are calculated in this file (last rows with a bold font).</p>
Replication Data for "How Closely are Common Mutation Operators Coupled to Real Faults?"
<p># Replication Data for "How Closely are Common Mutation Operators Coupled to Real Faults?"</p> <p>## Overview</p> <p>In mutation testing, faulty versions of a program are generated through automated modifications of source code. These mutants are used to assess and improve test suite quality, under the assumption that detection of mutants is indicative of a test suite's ability to detect real faults - i.e., that mutants and faults have a semantic relationship. Improving the effectiveness - in both cost and quality - of mutation testing may lie in better understanding this relationship, in particular with regard to how individual mutation operators (types) couple to real faults. </p> <p>In this study, we examine coupling between 32,002 mutants produced by 31 mutation operators and 144 real faults, using a scale based on number of failing tests and reasons for failure. Ultimately, we observed that 9.92% of the mutants are strongly coupled to real faults, and 51.03% of the faults have at least one strongly coupled mutant. We identify and examine mutation operators with the highest median coupling, as well as the operators that tend to produce non-compiling mutants, undetected mutants, and mutants that cause the most tests to fail outside of the tests that detect the actual fault. We also examine how coupling could be used to filter the set of operators employed, leading to potentially significant cost savings during mutation testing. Our findings could lead to improvements in how mutation testing is applied, improved implementation of specific mutation operators, and inspiration for new mutation operators. </p> <p>## Data Contained in This Package</p> <p>- mutant_data.csv</p> <p>This dataset contains the coupling results for all mutants considered in our experiments. It contains the following attributes for each mutant:</p> <p>-- Project name from Defects4J<br> -- Fault number from Defects4J<br> -- Mutation ID<br> -- Mutation operator<br> -- Number of trigger tests for the fault (tests that detect the real fault)<br> -- Number of failing test cases for the mutant (-1 indicates a compilation error)<br> -- The number of failing trigger tests for the mutant<br> -- The number of trigger tests that fail for the same reason the tests failed for the real fault.<br> -- The number of failing non-trigger tests.<br> -- The categorization of coupling. In order: Compile Error, Not Detected, No Substitution, Partial Test Substitution + Additional Tests Fail, Partial Test Substitution, Partial Substitution + Additional Tests Fail, Partial Substitution, Test Substitution + Additional Tests Fail, Test Substitution, Strong Substitution + Additional Tests Fail, Strong Substitution. </p> <p>- mutant_logs/{Project}/{Project}{Fault Number}output.txt</p> <p>The raw output log that resulted from executing test cases for each mutant for each case example used from Defects4J. Used to generate the dataset discussed above. Scripting for generating the dataset is also included.</p>
MATLAB Codes for: A Neural Network Weights Initialization Approach for Diagnosing Real Aircraft Engine Inter-Shaft Bearing Faults
<p><strong>Description:</strong></p> <p>This repository contains the MATLAB codes used in our paper [1] on fault diagnosis of inter-shaft aircraft bearings, published by MDPI Machines. The codes encompass all the necessary materials to reproduce the findings outlined in the paper. </p> <p><strong>Dataset Access:</strong></p> <p>The dataset utilized in this study is available under request from the authors of reference [8] in our paper. To obtain the dataset, please follow the instructions provided by the respective authors.</p> <p><strong>Data Format:</strong></p> <p>The dataset is saved in '*.npy' 3D variable format. To reproduce this study, it is necessary to transform these variables to '.mat' format since the codes are implemented in MATLAB. You can find the codes for transferring the 3D '*.npy' files to '*.mat' files here [<a href="../records/10184606">here</a>]</p> <p>We appreciate your interest in our work.</p> <p>[1] Berghout, Tarek, Toufik Bentrcia, Wei Hong Lim, and Mohamed Benbouzid. 2023. "A Neural Network Weights Initialization Approach for Diagnosing Real Aircraft Engine Inter-Shaft Bearing Faults" <em>Machines</em> 11, no. 12: 1089. https://doi.org/10.3390/machines11121089</p>
Mutation Testing of Deep Reinforcement Learning Based on Real Faults
<p>Trained agents to be used in the replication package of the paper "<em>Mutation Testing of Deep Reinforcement Learning Based on Real Faults</em>" accepted to the International Conference on Software Testing (ICST) 2023. The replication package is at https://github.com/FlowSs/RLMutation.</p>
Mutation Testing of Deep Reinforcement Learning Based on Real Faults
<p>Trained agents to be used in the replication package of the paper "<em>Mutation Testing of Deep Reinforcement Learning Based on Real Faults</em>" submitted to the International Conference on Software Engineering (ICST) 2023. Authors are set to anonymous for the peer-review process.</p>
ScienceDex guides
Understand access before you commit
These curated guides explain access requirements, typical timelines, costs, and reuse considerations for widely used research datasets.
Allen Brain Atlas
Allen Brain Atlas is an Allen Institute collection of brain map atlases, datasets, APIs, and analysis tools covering mouse, human, and non-human primate brain resources.
Annotated Behaviour and Observability Dataset (ABODe)
ABODe is a University of Edinburgh DataShare dataset for behavior classification in group-housed mice using home-cage video, identities, bounding boxes, ground-plate positions, and annotator labels.
DANDI Archive for NWB datasets
DANDI is a BRAIN Initiative archive for publishing and sharing neurophysiology data, including electrophysiology, optophysiology, and behavioral data packaged as NWB and related standards.
International Brain Laboratory public data
The International Brain Laboratory public data releases expose standardized mouse decision-making experiments, including Neuropixels recordings, widefield calcium imaging, behavior, and session metadata accessed through the ONE API.
OpenNeuro
OpenNeuro is a free, open platform for sharing neuroimaging datasets, with public search, dataset pages, and download paths for web, S3, DataLad, and the OpenNeuro CLI.