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.
73
datasets available to search
ShareScore release 0.9.0
Dataset results
73 results for “performance results”
Performance of users with Cerebral Palsy playing GABLE Games together with their results to the Left/Right Dynamic balance tool
<p>This dataset contains data generated by users of GABLE platform. The data shows the performance of some users with Cerebral Palsy playing GABLE Games together with their results to the Left/Right Dynamic balance tool. More information about GABLE project can be found at: www.projectgable.eu</p>
End-user's survey results on needs and expectations for next- generation Energy Performance Certificates (H2020 X-tendo project)
<p>The SPSS data file consists of survey data from the X-tendo project on the end-user needs and expectations from next-generation energy performance certificates.</p>
Experiment on the performance of different machine learning algorithms for classification - Results
<h2>Results of a short performance study of machine learning algorithms</h2> <h3>Context and methodology</h3> <ul> <li>This data was produced while performing a university project to examine the performance of various machine learning algorithms on different prediction datasets</li> <li>The data serves the purpose of comparing the metrics of performing the different tasks</li> <li>The dataset contains a number of matrices for every classifier and every dataset</li> <li>The data was produced with python scripts provided further down and with the usage of the external datasets: <ul> <li>Membership Woes Dataset (OpenML): <a href="https://api.openml.org/d/44224">https://api.openml.org/d/44224</a></li> <li>Zoo dataset (UCI): <a href="https://doi.org/10.24432/C5R59V">https://doi.org/10.24432/C5R59V</a></li> <li>Breast Cancer Dataset: <a href="https://github.com/moritx/performance-experiment-machine-learning/tree/main/data">https://github.com/moritx/performance-experiment-machine-learning/tree/main/data</a></li> <li>Loan Dataset: <a href="https://github.com/moritx/performance-experiment-machine-learning/tree/main/data">https://github.com/moritx/performance-experiment-machine-learning/tree/main/data</a></li> </ul> </li> </ul> <h3>Technical details</h3> <ul> <li>The data consists of one JSON file</li> <li>The source code for producing this data is available at <a href="https://doi.org/10.5281/zenodo.11085222">https://doi.org/10.5281/zenodo.11085222</a></li> </ul> <h3>Structure of the data</h3> <p>[ {"classifier": ...,<br>"dataset": ...,<br>"hyper_parameters": ...,<br>"cross_validation_results": {<br> "fit_time": {} ,<br> "score_time": ...,<br> "metrics": {}<br>}, <br>"holdout_test_results": ...}, ]</p>
Deliverable 1.1.1.1 BEL-Float project | Dataset containing the results of numerical simulations (motions, forces) of the operational performance analysis - Input files
<p>This dataset contains the parent input used to generate the simulation files of the DeepCwind OC4 semi-submersible combined with the 5MW NREL turbine for various wind and wave conditions. The basis of the OpenFAST input files are taken from <a href="https://github.com/OpenFAST/r-test/tree/main/glue-codes/openfast/5MW_OC4Semi_WSt_WavesWN">OpenFAST r-test GitHub repository (5MW_OC4Semi_WSt_WavesWN)</a> and adapted to simulate various wind and wave conditions. The turbulent wind field as the input to the InflowWind module is generated using <a href="https://www.nrel.gov/wind/nwtc/turbsim.html">TurbSim</a>. The simulations are performed on a modified version of OpenFAST v3.5.3 to which adaptation to the code is made to extract additional Morison drag output up to 16 cylindrical members. This adapted code is <a href="https://github.com/abkpribadi/openfast/tree/Morison_additional_output">uploaded on GitHub as a branch from a forked OpenFAST repository</a>. In total there are 1152 simulation results consists of 768 irregular waves and 384 regular waves cases. The complete dataset is divided into 9 sub-datasets, see "Related work" section. A report describing this dataset will be made available on BEL-Float project website by November 2024: https://www.owi-lab.be/bel-float.</p>
DRALOD D1.3 Results of performance testing of the prototype of energy recovery system data set
<p>Data set for delivery D1.3 Results of performance testing of the prototype of energy recovery system </p>
HeatResilientCity II - work package 2.2: Influence of regional and urban climate on indoor overheating - Results of building performance simulation
<p>This repository contains the <strong>results of the building performance simulations</strong> carried out in the working package 2.2 Influence of regional and urban climate on indoor overheating of the project <a href="http://heatresilientcity.de/">HeatResilientCity II</a>. The buildings under consideration are a multi-residential so-called ‘Gründerzeithaus’ (GZH) and a large-panel construction (LPC) building. The results were extracted for two rooms on the top floor/attic of each building and follow a consistent name convention. Each file contains hourly resolved values for the outdoor air temperature, the indoor air temperature, the indoor operative temperature and the relative humidity indoors and outdoors. Further information can be found in the README of this repository. The simulations were performed for five <strong>different</strong> <strong>regions</strong> in Germany (Dresden, Hamburg, Köln, Stuttgart and Potsdam) for <strong>average present</strong> and <strong>future</strong> <strong>summers</strong> based on meteorological measurement data and under consideration of <strong>urban</strong> <strong>climate</strong>.</p> <p>In addition to the ‘plain’ simulation results, some <strong>heat-indicator variables</strong> were calculated and listed in the files <em>Calculated_Variables.txt</em>. The calculated quantities include temperature-weighted exceedance hours (TWEH) for the limits of 25, 26 and 27 °C (defined in DIN 4108-2:2013 as ‘Übertemperaturgradstunden’) and the maximum operative temperature calculated for the period from April to September.</p> <p>The used <strong>input data</strong> and <strong>building models</strong> can be found in the related repository.</p>
Why, what and how do European healthcare managers use performance data? Results of a survey and workshop among members of the European Hospital and Healthcare Federation (Data set; anonymised)
<p>The dataset presents results of a descriptive cross-sectional study based on a survey, delivered through an online self-reported questionnaire. The questionnaire was distributed to managers of hospitals and other health care organisations in a purposive sample of participants to the Exchange Programmes of the European Hospital and Health Care Federation (HOPE) eliciting information on the actual use of performance data in hospitals and other healthcare organisations in Europe in 2019.<br> Data collected through the online questionnaire was analysed using univariate descriptive statistics. Analyses were conducted using the R statistical program version 3.6.1. Respondents were, for certain parts of the analysis, sub-grouped by their reported managerial position and experience, as well as the type of organisation they work for. Analysis was done on a full sample of respondents, including the primary, 2019 HOPE Exchange Programme participants, and the secondary study population, 2015-2018 Exchange Programme alumni and local hosts.</p>
Experiment Results: Evaluation of different parallelisation strategies with regard to the performance of parallel program execution
<p><br> Modern processors achieve an increase in performance by adding multiple cores. This means that during software development, care must be taken to parallelise the program sequences. To make predictions about the performance of a software design, there is Palladio. This is very accurate for single core processors.<br> In this bachelor thesis the influence of the chosen parallelization strategy on the performance of software is examined. Different hardware requirements are used for this purpose. They are used to generate individual work packages. These are executed by different parallelization strategies. The used parallelization strategies are: Java Threads, Java ParallelStreams, OpenMp and Akka Actor. Runtime and cache behavior are measured during each execution. In addition, the experiments are performed on different servers. The evaluation is done using acceleration curves and the Cache Miss Rate. The results show that the parallelization strategies differ only slightly in the work packages used.</p>
Performance results of LeanMD on the Joliot-Curie supercomputer using different load balancing algorithms
<p>This dataset contains the raw output files generated from the execution of LeanMD on the Joliot-Curie supercomputer (20 SKL Irene nodes), the scripts used to generate them, and the scripts used to parse these results for statistical analysis and plotting.</p> <p><strong>Software information</strong>:</p> <ul> <li>OS: Red Hat Enterprise Linux 7.6</li> <li>OpenMPI: version 2.0.4</li> <li>Compilers: C/C++ Intel 17.0.6.256</li> <li>Charm++ version: v6.9.0-rc3, build mpi-linux-x86_64 --with-production</li> <li>LeanMD source: <a href="https://charm.cs.illinois.edu/gerrit/gitweb?p=benchmarks/leanmd.git">https://charm.cs.illinois.edu/gerrit/gitweb?p=benchmarks/leanmd.git</a></li> <li>Additional load balancers source: <a href="https://github.com/viniciusmctf/packing-schemes/tree/packs_2019-v1">https://github.com/viniciusmctf/packing-schemes/tree/packs_2019-v1</a></li> <li>Charm++, LeanMD, and the load balancers were compiled with -O3</li> </ul> <p><strong>File information</strong>:</p> <p>The raw result files are organized in four directories (oct18, oct23, oct24, and oct24_2).<br> Each directory contains the results of one batched execution in the supercomputer.<br> Each batch is composed of 10 repetitions of a set of experiments.<br> Each set of experiments includes different load balancing algorithms and different problem sizes.<br> Each set is randomly ordered to avoid interference coming from a specific order of execution.<br> Each raw file contains the appended output of the application and its load balancer for all 10 repetitions.<br> The name of the files indicate the load balancer and size of the problem.<br> For instance, `PackStealLB.240` means that the application was run with PackStealLB and the problem size parameter is 240.</p> <p><strong>Problem sizes</strong>:</p> <ul> <li>80: 80×11×5 cells of dimensions 15×15×30</li> <li>120: 120×11×5 cells of dimensions 15×15×30</li> <li>160: 160×11×5 cells of dimensions 15×15×30</li> <li>240: 240×11×5 cells of dimensions 15×15×30</li> <li>320: 320×11×5 cells of dimensions 15×15×30</li> </ul> <p>Each execution of LeanMD ran for 301 iterations with load balancing calls at iterations 40, 140, and 240.</p> <p><strong>Raw output files</strong>:</p> <p>Each raw output file starts with a Charm++ header providing information on the execution.</p> <p>For each step of the application, its execution time in ms is provided.</p> <p>Load balancing calls usually provide information about their start time, end time, and duration. Depending on the load balancer, more information is provided.</p> <p>Each raw file contains ten executions of the application with a given load balancer and input size.</p> <p><strong>Generating plots</strong>:</p> <p>The analysis of the results can be done by running the Jupyter notebook named "Analysis of load balancing results.ipynb"</p>
Toward Estimating the Rank Correlation between the Test Collection Results and the True System Performance
<p>This archive contains the simulated collections and the estimated correlation coefficients. For the full code and description, please refer to https://github.com/julian-urbano/sigir2016-correlation</p>
Scalability, dynamicity and performance evaluation results of Mantus framework
<p>Datasets used for experimental results (Figure 5): (a) Compositional weaver efficiency; (b) incremental weaving efficiency; (c) relative overhead of weaving in workflow; (d) weaver efficiency vs. aspect complexity.</p> <p>Type of data: raw and processed</p> <p>Hardware/software used: Intel Xeon E5-2650 Haswell at 2.60GHz with 64 GB of RAM; Testing input for all Mantus benchmarks: OpenStack-based ORBITS template described in paper, composed of a controller node and of 3 different group instances of compute nodes (Xen, KVM, LXC), with two virtual networks and relative network resources.</p> <p>Data format: CSV</p> <p>Source: Experiments</p> <p> </p>
Data Results from Performance Modelling of SLAM methods
<p>Data from runs/bencmarks of SLAM methods GMapping, SLAM Toolbox and Hector SLAM.</p> <p>Results include data for multiple performance metrics, parameters of the robot sensors, and environment features. The data contains results from many runs executed with various combinations of parameters in order to create a statistical model of the SLAM performance in function of characteristics of the robot and environment.</p>
Results for Performance Comparison of kNN and GD
<p>Results for the project Performance Comparison of kNN and GD. Contains results for GD and KNN for both fish and employee datasets.</p>
Performance results of different scheduling algorithms used in the simulation of a modern game engine
<p><strong>Performance results of different scheduling algorithms used in the simulation of a modern game engine</strong></p> <p>These results are a companion to the paper entitled "<em>Exploring scheduling algorithms for parallel task graphs: a modern game engine case study</em>" by M. Regragui et al.</p> <p><strong>General information</strong></p> <p>This dataset contains raw outputs and scripts to visualize and analyze the scheduling results from our game engine simulator.<br> The result analysis can be directly reproduced using the script run_analysis.sh. A series of Jupyter Notebook files are also available to help visualize the results.</p> <p><strong>File information</strong></p> <p>- All Scenario*.ipynb files contain python scripts to visualize and analyze the simulation results.<br> - The Scenario*.py files contain python scripts that can be run directly with Jupyter Notebook.<br> - The requirements.txt file contains the names and versions of python packages necessary to reproduce the analysis.<br> - The run_analysis.sh file contains a bash script to install the required python packages and run the Scenario*.py scripts.</p> <p>The results are organized in five folders:</p> <p>1. Result_1 contains the results for Scenario 1 generated using file input_scenario_1.txt.<br> 2. Result_2 contains the results for Scenario 2 generated using file input_scenario_2.txt.<br> 3. Result_3 contains the results for Scenario 3 generated using file input_scenario_3.txt.<br> 4. Result_CP_1 contains the results for the critical path of Scenarios 1 and 2 generated using file input_CP_scenario_1.txt.<br> 5. Result_CP_3 contains the results for the critical path of Scenario 3 generated using file input_CP_scenario_3.txt.</p> <p>Each result file (e.g., HLF_NonSorted_Random_1_200_10.txt) contains 200 lines representing information of the 200 frames that were simulated. Each line contains four values: the frame number, the duration of the frame (in microseconds), a critical path estimation for the previous frame (in microseconds), and the load parameter (value between 0 and 1).</p> <p>The outputs of this analysis include some PDF files representing the figures in the paper (in order) and some CSV files representing the values shown in tables. The standard output shows the p-values computed in parts of the statistical analysis.</p> <p><strong>Software and hardware information</strong></p> <p>The simulation results were generated on an Intel Core i7-1185G7 processor, with 32 GB of LPDDR4 RAM (3200 MHz). The machine ran on Ubuntu 20.04.3 LTS (5.14.0-1034-oem), and g++ 9.4.0 was used for the simulator's compilation (-O3 flag).</p> <p>The results were analyzed using Python 3.8.10, pip 20.0.2 and jupyter-notebook 6.0.3. The following packages and their respective versions were used:</p> <p>- pandas 1.3.2<br> - numpy 1.21.2<br> - matplotlib 3.4.3<br> - seaborn 0.11.2<br> - scipy 1.7.1<br> - pytz 2019.3<br> - python-dateutil 2.7.3<br> - kiwisolver 1.3.2 <br> - pyparsing 2.4.7 <br> - cycler 0.10.0 <br> - Pillow 7.0.0<br> - six 1.14.0 </p> <p><strong>Simulation information</strong></p> <p>Simulation results were generated from 4 to 20 resources. Each configuration was run with 50 different RNG seeds (1 up to 50).</p> <p>Each simulation is composed of 200 frames. The load parameter (lag) starts at zero and increases by 0.01 with each frame up to a value equal to 100% in frame 101. After that, the load parameter starts to decrease in the same rhythm down to 0.01 in frame 200.</p> <p><strong>Algorithms abbreviation in presentation order</strong></p> <p>FIFO serves as the baseline for comparisons.</p> <p>1. FIFO: First In First Out.<br> 2. LPT: Longest Processing Time First.<br> 3. SPT: Shortest Processing Time First.<br> 4. SLPT: LPT at a subtask level.<br> 5. SSPT: SPT at a subtask level.<br> 6. HRRN: Highest Response Ratio Next. <br> 7. WT: Longest Waiting Time First.<br> 8. HLF: Hu's Level First with unitary processing time of each task.<br> 9. HLFET: HLF with estimated times.<br> 10. CG: Coffman-Graham's Algorithm.<br> 11. DCP: Dynamic Critical Path Priority.</p> <p><strong>Metrics</strong></p> <p>* SF: slowest frame (maximum frame execution time)<br> * DF: number of delayed frames (with 16.667 ms as the due date)<br> * CS: cumulative slowdown (with 16.667 ms as the due date)<br> </p>
Performance results of ARMOSA model parallelized with COMPSs
<p>Scripts and data results to build the performance graph of the LandSupport ARMOSA application parallelized with COMPSs. This results have been published in D3.6 - REPORT ON THE FINAL MODELS IMPLEMENTATION AND OPTIMIZATION.</p> <p>The archive contains the python script to generate the graphs, and the dataset of the times resulting from the execution of the application in the LandSupport platform. The execution times can only be generated on such platform.</p>
Survey questionnaire and results on Pay-for-Performance (P4P) schemes for energy efficiency measures
<p>The online survey was designed and conducted in the framework of the EU H2020 SENSEI project. The aim of the survey was to identify stakeholders’ perceptions on how P4P programmes could be integrated into the existing EU regulatory and market framework. We developed a semi-quantitative, self-completion online questionnaire, using the online tool “Alchemer”. The online survey collects input from different experts from the field of academia, consultancies, policymaking, and the energy industry. </p> <p>The questionnaire is used by <em>Tzani</em> <em>et al </em>(2022) to investigate how policy developments and adjustments in the EU can facilitate the design of performance-based energy efficiency programmes. The study combines a Strengths, Weaknesses, Opportunities, and Threats framework with an Analytical Hierarchy Process method and a Threats, Opportunities, Weaknesses, and Strengths matrix for the analysis of different stakeholder perceptions and the formulation of policy strategies.</p> <p>If you use this questionnaire in an academic publication, please cite the corresponding article:</p> <p><em>Tzani, D., Exintaveloni, D.S., Stavrakas, V., Flamos, A. </em><em>Devising policy strategies for the deployment of energy efficiency Pay-for-Performance programmes in the European Union</em><em>. </em></p>
Results of elemental analyses of brain and liver human tissue samples performed by inductively coupled plasma mass spectrometry
<p>Human tissue samples of brain and liver were obtained after min. 24 h postmortem from the Department of Forensic Medicine, University of Lublin. Tissue samples were collected from typical anatomical locations intended for histopathological examination: A—polus frontalis (frontal pole), B—gyrus precentralis (precentral gyrus), C—gyrus postcentralis (postcentral gyrus), D—cortex cingularis (gyrus cinguli cingulate gyrus), E—hippocampus (hippocampus), F—caput nuclei caudati (head of caudate nucleus), G—fasciculus longitudinalis superior cerebri (superior longitudinal fasciculus of brain, SLF), H—fasciculus longitudinalis inferior cerebri (inferior longitudinal fasciculus of brain, ILF), I—thalamus dorsalis (dorsal thalamus), J—nucleus accumbens septi (nucleus accumbens septi, NAc), K—insula (insula), L—hepar (liver). Samples were taken with the consent of the prosecutor and the Local Bioethics Committee (Medical University of Lublin, Poland, KE-0254/152/2021, approval date 24 June 2021). The study was conducted in accordance with the World Medical Association Code of Ethics, Declaration of Helsinki, for experiments involving human subjects. The samples were mineralized to remove the organic matrix using microwave minerali-zation with nitric acid (69% suprapur HNO3, Baker, Radnor, PA, USA) in the microwave mineralization system Multiwave 5000 (Anton Paar, Graz, Austria). After mineralization step, HCl (Merck, Darmstadt, Germany) was added and diluted by ultrapure water. The elemental analysis was performed using the inductively coupled plasma mass spectrometer Agilent 8900 ICP-MS Triple Quad (Agilent, Santa Clara, CA, USA). </p>
Results from Performance Evaluation and Testing of Virtual Infrastructure Managers
<p>NFV leverages Cloud Computing principles to move the data-plane network functions from expensive, closed and proprietary hardware to so-called Virtual Network Functions (VNFs). We deal with the management of virtual computing resources (Unikernels) for the execution of VNFs. This functionality is performed by the Virtual Infrastructure Manager (VIM) in the NFV MANagement and Orchestration (MANO) reference architecture. In this data set we report the results of a performance evaluation we have realized of three open source VIMs, namely OpenStack, Nomad and OpenVIM; both considering stock and the tuned versions. The VIMs and the performance evaluation tools that we employ are provided openly and can be downloaded from our repositories (<a href="https://github.com/superfluidity/openvim4unikernels">https://github.com/superfluidity/openvim4unikernels</a> and <a href="https://github.com/netgroup/vim-tuning-and-eval-tools">https://github.com/netgroup/vim-tuning-and-eval-tools</a>).</p>
Task Scheduler Performance Survey Results
<p><strong>Task scheduler performance survey</strong></p> <p>This dataset contains results of task graph scheduler performance survey.<br> The results are stored in the following files, which correspond to simulations performed on <br> the `elementary`, `irw` and `pegasus` task graph datasets published at https://doi.org/10.5281/zenodo.2630384.</p> <ul> <li>elementary-result.zip</li> <li>irw-result.zip</li> <li>pegasus-result.zip</li> </ul> <p>The files contain compressed pandas dataframes in CSV format, it can be read with the following Python code:<br> ```python<br> import pandas as pd<br> frame = pd.read_csv("elementary-result.zip")<br> ```</p> <p>Each row in the frame corresponds to a single instance of a task graph that<br> was simulated with a specific configuration (network model, scheduler etc.).<br> The list below summarizes the meaning of the individual columns.</p> <ul> <li><strong>graph_name</strong> - name of the benchmarked task graph</li> <li><strong>graph_set</strong> - name of the task graph dataset from which the graph originates</li> <li><strong>graph_id</strong> - unique ID of the graph</li> <li><strong>cluster_name</strong> - type of cluster used in this instance the format is <number-of-workers>x<number-of-cores>; 32x16 means 32 workers, each with 16 cores</li> <li><strong>bandwidth</strong> - network bandwidth [MiB]</li> <li><strong>netmodel</strong> - network model (simple or maxmin)</li> <li><strong>scheduler_name</strong> - name of the scheduler</li> <li><strong>imode</strong> - information mode</li> <li><strong>min_sched_interval</strong> - minimal scheduling delay [s]</li> <li><strong>sched_time</strong> - duration of each scheduler invocation [s]</li> <li><strong>time</strong> - simulated makespan of the task graph execution [s]</li> <li><strong>execution_time </strong>- real duration of all scheduler invocations [s]</li> <li><strong>total_transfer</strong> - amount of data transferred amongst workers [MiB]</li> </ul> <p>The file `charts.zip` contains charts obtained by processing the datasets.<br> On the X axis there is always bandwidth in [MiB/s].<br> There are the following files:</p> <ul> <li>[DATASET]-schedulers-time - Absolute makespan produced by schedulers [seconds] </li> <li>[DATASET]-schedulers-score - The same as above but normalized with respect to the best schedule (shortest makespan) for the given configuration.</li> <li>[DATASET]-schedulers-transfer - Sums of transfers between all workers for a given configuration [MiB]</li> <li>[DATASET]-[CLUSTER]-netmodel-time - Comparison of netmodels, absolute times [seconds]</li> <li>[DATASET]-[CLUSTER]-netmodel-score - Comparison of netmodels, normalized to the average of model "simple"</li> <li>[DATASET]-[CLUSTER]-netmodel-transfer - Comparison of netmodels, sum of transfered data between all workers [MiB]</li> <li>[DATASET]-[CLUSTER]-schedtime-time - Comparison of MSD, absolute times [seconds]</li> <li>[DATASET]-[CLUSTER]-schedtime-score - Comparison of MSD, normalized to the average of "MSD=0.0" case</li> <li>[DATASET]-[CLUSTER]-imode-time - Comparison of Imodes, absolute times [seconds]</li> <li>[DATASET]-[CLUSTER]-imode-score - Comparison of Imodes, normalized to the average of "exact" imode</li> </ul> <p><strong>Reproducing the results</strong></p> <p><em>1. Download and install Estee (https://github.com/It4innovations/estee)</em></p> <p>$ git clone https://github.com/It4innovations/estee<br> $ cd estee<br> $ pip install .<br> <br> <em>2. Generate task graphs</em><br> You can either use the provided script `benchmarks/generate.py` to generate graphs<br> from three categories (elementary, irw and pegasus):</p> <p>$ cd benchmarks<br> $ python generate.py elementary.zip elementary<br> $ python generate.py irw.zip irw<br> $ python generate.py pegasus.zip pegasus<br> <br> or use our task graph dataset that is provided at https://doi.org/10.5281/zenodo.2630384.</p> <p><em>3. Run benchmarks</em><br> To run a benchmark suite, you should prepare a JSON file describing the benchmark.<br> The file that was used to run experiments from the paper is provided in<br> `benchmark.json`. Then you can run the benchmark using this command:<br> <br> $ python pbs.py compute benchmark.json</p> <p>The benchmark script can be interrupted at any time (for example using Ctrl+C).<br> When interrupted, it will store the computed results to the result file and restore<br> the computation when launched again.</p> <p><em>3. Visualizing results</em><br> <br> $ python view.py --all <result-file><br> <br> The resulting plots will appear in a folder called `outputs`.</p>
On the Performance of Method-Level Bug Prediction: A Negative Result
<p>Bug prediction is aimed at identifying software artifacts that are more likely to be defective in the future. Most approaches defined so far target the prediction of bugs at class/file level. Nevertheless, past research has provided evidence that this granularity is too coarse-grained for its use in practice. As a consequence, researchers have started proposing defect prediction models targeting a finer granularity (particularly method-level granularity), providing promising evidence that it is possible to operate at this level. Particularly, models mixing product and process metrics provided the best results.</p> <p>We present a study in which we first replicate previous research on method-level bug-prediction, by using different systems and timespans. Afterward, based on the limitations of existing research, we (1) re-evaluate method-level bug prediction models more realistically and (2) analyze whether alternative features based on textual aspects, code smells, and developer-related factors can be exploited to improve method-level bug prediction abilities. Key results of our study include that (1) the performance of the previously proposed models, tested using the same strategy but on different systems/timespans, is confirmed; but, (2) when evaluated with a more practical strategy, all the models show a dramatic drop in performance, with results close to that of a random classifier. Finally, we find that (3) the contribution of alternative features within such models is limited and unable to improve the prediction capabilities significantly. As a consequence, our replication and negative results indicate that method-level bug prediction is still an open challenge.</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.