dataesr/scientific-paragraphs-categorization huggingface dataset:
Extracting AST Actions from Updated Files In the second step, RSCommitDetector computes the differences between the pair of files <f p , f n > (line 8). The output of this step is a diff, it comes in the form of an edit script (ES), a list of actions that transforms f p into f n. RSCommitDetector computes these actions at the AST level using the GumTree algorithm  [9]. There are four types of action: 1) update, which changes the value of an AST node, 2) insert, which inserts a new AST node, 3) delete, which deletes an existing AST node, and 4) move, which moves an AST node and makes it child of another node. These extracted fine-grained AST actions are passed to the next step.
Change Pattern Specification. In RSCommitDetector, each pattern specifies a specific repair strategy of a program repair system. The patterns are represented in the change pattern specification language of Martinez et al. [28] , which we now briefly present. A change pattern consists of a set of actions, and each action is performed on an entity. The types of actions of pattern specifications are the same as the types of AST actions that GumTree extracts (update, insert, delete, and move). In addition to these action types, a change pattern can also contain an action of unchanged type, which indicates an entity should not be changed (i. e. , not affected by any action). Finally, a change pattern can also define parenthood relations between entities. For example, Listing 2 is a change pattern that corresponds to a repair strategy used by jMutRepair  [26].
Change Pattern Matching. For each change pattern specification p of a repair system, RSCommitDetector checks if p matches with the AST actions (ES) previously computed (line 10). To this end, for each action A p specified in p, RSCommitDetector checks whether there exists an actual action in ES that affects the nodes specified by A p. Moreover, every action in ES should correspond to for each file f in дetU pdatedFiles(c) do 6: f p ← дetPreviousV ersion(f ) 7: f n ← дetN ewV ersion(f ) 8: ES ← GetDi f f (f p , f n ) /* ES: Edit Script */ 9: for each pattern p in patterns do 10: if instanceO f (ES, p) then 11:.
Repair Systems Considered In this paper, we specify the search space of eight repair systems: Arja  [47] , Cardumen  [27] , Elixir  [37] , GenProg  [18] , jMutRepair  [26] , Kali  [35] , Nopol  [45] , and NPEfix  [4]. We choose these tools because they are considered in the RepairThemAll experiment  [6] , which is to our knowledge, the largest repair experiment done to date. In Table  1 , each row presents a brief overview of the change patterns and the post-matching rules that we consider to encode the search space of the corresponding repair system. For instance, three change patterns are considered to encode the repair strategies employed by Arja, one for inserting a new statement, one for removing a statement, and one for replacing a statement. Moreover, in accordance with the process of synthesizing new statements in Arja, we have a post-matching rule: the new statement should be a copy of an existing statement, while the variables, literals, and methods can be replaced by other variables, literals, and methods in the scope.
Implementation RSCommitDetector is built on top of Coming  [28]. Coming is designed to mine instances of code change patterns in Git repositories. We extend Coming by adding change pattern specifications and post-matching rules for the considered repair systems. The post-matching rules are implemented in Java and the patterns are represented in change pattern specification language  [28]  as noted in Section 3. 4. 1. For all systems based on code reuse, RSCommitDetector considers that the scope of ingredients is at the same file level. This means a repair-space commit must utilize ingredients from the same file as the repair location. For sake of open science, RSCommitDetector is publicly available  [1].
EXPERIMENTAL METHODOLOGY 4. 1 Research Questions In this paper, we study four research questions: the first one concerns a longitudinal analysis of the applicability of program repair on past commits, and the other three are investigations of the complexity and accuracy of RSCommitDetector. • RQ1: How common are commits that lie in the search space of program repair systems? Previous work has shown the strategies introduced by repair systems are useful for fixing bugs. However, no one has studied to what extent using those repair strategies is common in real-world programs. In this paper, we present RSCommitDetector and utilize it to answer this question. • RQ2: How complex are the commit matching criteria that encode the repair search space of program repair systems? RSCommitDetector specifies the search space of eight existing common repair systems.
Datasets In this paper we use two datasets: 1) a set of Github repositories, and 2) a set of patches (i. e. , source code changes) that are generated by automatic program repair systems. These repositories and patches are collected as follows. The dataset of repositories, which we call ProjFromBears, contains all the projects that are included in Bears  [24]. Bears focuses on 72 repositories. We consider projects of Bears since it has the most diverse set of repositories among existing bug datasets. The median numbers of Java files and commits are 357 and 1, 323, respectively. As shown in Figure  2 , the size of the history of projects are diverse, and some projects have even more than 10, 000 commits. The second dataset, named Ground-truth, is a benchmark of patches made by automatic repair systems.
This dataset is built by joining data from other datasets of patches, as follows. First, it includes all patches from DRR  [46] , DRR contains a collection of patches generated by repair systems on the Defects4J dataset 0 5000 10000 15000 20000 Figure  2 : The distribution of the number of commits in the considered projects, the median is 1, 323 commits, which shows that the BEARS dataset is composed of serious opensource projects. [14]. Second, the Ground-truth dataset includes the patches from NPEfix  [5]. The Ground-truth dataset contains 1, 065 patches in total. Cardumen has the highest number of ground-truth patches (285) and Elixir has the lowest (41).
Protocol for RQ1 We use RSCommitDetector to answer RQ1. We run RSCommitDetector on all repositories included in the ProjFromBears dataset. This experiment is carried out in form of a sequence of executions. Each execution is represented by a pair <repair_system, repository>. In total, we perform 576 (8 tools × 72 projects) executions. In each execution, RSCommitDetector goes through the commits of repository and checks if the source code changes in each commit are in the search space of repair_system. The time limit for each execution is set to 30 minutes and commits are considered from the oldest one to the most recent one. The result of this experiment is a set of repair-space commits for each <repair_tool, repository> pair. Based on those results, we look at which systems have the widest applicability, i.
Protocol for RQ3 To answer RQ3, we design an experiment to determine how many of the patches actually generated by a repair system are correctly detected by RSCommitDetector. For this, we run RSCommitDetector on the Ground-truth dataset. Ideally, RSCommitDetector should be able to detect all of these source code changes as instances of corresponding repair systems. However, it might happen that ground-truth patches cannot be detected by RSCommitDetector due to the inaccuracy of how we encode the search space of repair systems. We call these patches the false negatives patches (FN). Moreover, there are ground-truth patches which do not follow the post-matching rules. For example, some jGenProg ground-truth patches insert statements selected from source files other than the changing file. Which means in these ground-truth patches the scope of ingredients is not at the same file level.
Protocol for RQ4 We measure the precision of RSCommitDetector as follows: we randomly select 30 of the commits that are detected as repair-space commits of each tool in RQ1 experiment. Next, we carry out a manual analysis to decide if the detected repair-space commits actually lie of the search space of corresponding repair systems or not. This manual analysis has seven participants, all of whom are researchers in the field of automatic program repair: three PhD students, two postdoctoral researchers, and two professors. Each commit is annotated by two participants. If the first two annotations conflict with each other, a third participant annotates to break the tie. All results from this experiment are publicly available (see  [1] ). The precision for each repair system is computed due to Equation 2.
Moreover, 29 of these 303 commits are not detected as repair-space commits for any other systems. In total, 737 (1. 77%) commits are considered repair-space commits for, at least, one of the repair systems. Among the considered repair systems, the search space of three of them cover more than 0. 5% of the commits: Arja, Elixir, and GenProg. Given the change patterns used by these three systems, we can conclude that adding and replacing statements with other statements from the same file are common in the open-source Java projects. This result confirms and strengthens the external validity of  [29]. This percentage is over all commits. An interesting related percentage is the percentage of bug-fix commits that are in the search space of program repair systems. Soto et al. showed that 19% of commits of their dataset are bug-fix commits  [40] , consequently, we can estimate that in our dataset, there are 41, 612 * 0.
19 = 7, 906 bugfix commits. This yields a percentage of bug-fix commits that are in program repair search space, of approximately 737/7, 906 = 9. 3% on Bears. Interestingly, this corresponds nicely with the results of Durieux et al. [6] , who showed that the considered repair systems can fix 9. 9% of the bugs in the Bears benchmark (those numbers are comparable because we consider the same projects from the same benchmark, see Section 4. 2). The consistency between a purely static approach as RSCommitDetector on past and the actual execution of program repair systems  [6]  jointly reinforce the external validity of both studies. Now, let us discuss the speed of the analysis. The average time spent to check if a commit is in the search space of a repair system is 0. 81 second. Elixir has the slowest patterns and post-matching rules, RSCommitDetector needs 1.
72 second to analyze if a commit is in the search space of Elixir. On the contrary, the RSCommit-Detector configured for Kali takes only 0. 29 second per commit. Those numbers indicate that RSCommitDetector can scale to large repositories: for instance, analyzing 3. 3k commits (the maximum number of commits for 99% of Java projects on Github) against the search space of all tools would take approximately 6 hours, which is acceptable given that it is one-short computation task. Answer to RQ1: How common are commits that lie in the search space of program repair systems? According to our analysis, 1. 77% (737/41, 612) of commits in 72 projects of ProjFromBears dataset are detected as being in the search space of at least one repair system. Elixir is the system whose search space covers the highest number of commits (0.
86%), while jMutRepair search space covers the lowest (0. 01%). RSCommitDetector is fast, it analyzes each commit against the search space of each tools in 0. 81 seconds on average. To the best of our knowledge, we are the very first to report on this percentage, to quantitatively measure the applicability of program repair in practice. Our results indicate that our approach can be used to collect large datasets of human-made commits that are amenable to program repair. Such datasets can then be utilized for different purposes, such as data-driven tuning of program repair systems  [22]  and training neural networks to generate commit messages for bug-fix commits  [13][31]. a RSC stands for "repair-space commits". This column shows how many of the 41, 612 commits that are analyzed against the search space of all tools are detected as repair-space commits of this system.
Complexity of Repair Search Space Encoding The results of the second experiment are shown in Table  3. Columns "#Patterns", "#Actions", and "#Entities" indicate the total number of change patterns, actions and entities inside them for each repair system that is implemented in RSCommitDetector (see Listing 2 and the discussion about it in Section 3. 4. 1 for details). The "LOC" column shows the number of Java code lines for the post-matching rules implementation. For instance, three change patterns are designed to encode the repair strategies employed by Arja. These patterns consist of four actions and five entities in total. Also, the post-matching rules are implemented in 343 lines of Java code. In total, we design 34 pattern specifications with 51 actions and 85 entities to encode the search space of all systems.
Among all the repair systems, Elixir search space has the most complex encoding patterns with 17 actions and 28 entities. Moreover, the implementation of post-matching rules contain 1, 806 lines of code in total. Arja has the largest post-matching rules with 343 lines. Answer to RQ2: How complex are the commit matching criteria that encode the repair search space of program repair systems? We are able to encode the search space of eight repair systems using 34 pattern specifications and 1, 806 lines of code. Elixir is the hardest search space to encode, while Kali and jMutRepair are the easiest ones. The biggest advantage of our approach to study the applicability of program repair is that it is purely static, it only requires to encode the search space with patterns and post-matching rules.
Recall of RSCommitDetector positive patches, respectively (see Section 4. 5 for more details). The recall is computed according to Equation  1. For instance, there are 128 ground-truth patches that are considered for Arja and RSCommitDetector detects 116 of them. Consequently, the recall for Arja is 0. 90. RSCommitDetector has the lowest recall for Elixir (0. 83) and the highest one for jMutRepair, a perfect recall of 1. The total recall is 0. 92. Since RSCommitDetector is the first tool of its type, there is no other work that we can directly compare against. However, a close task is just-in-time defect prediction, which is about predicting whether or not a code change introduces new bugs  [33]. To give a sense of perspective, the recall of a state-of-the-art tool in this area is 0. 65  [33] , which is well below our recall of 0.
83 and a median of 0. 905. Therefore, we conclude that RSCommitDetector can be trusted in terms of detecting commits that actually lie in search spaces of program repair. Researchers in program repair can rely on RSCommitDetector to perform a longitudinal analysis of other open-source projects that are not in the considered benchmark. Listing 5: Example of a wrongly detected Nopol repairspace commit. Nopol is not able to synthesize ternary expressions (conditions with "?" and ":" signs).
Generalizability of the Approach In this paper, we encode the search space of repair tools for matching commits in Java programs. We note that our approach is generic enough to identify repair-space commits written in other programming languages. To implement the approach for analyzing commits written in a new language, Table  1  provides the specification to encode the patterns and post-matching rules for matching this language. We note that the AST differencing library we use, GumTree, works for all mainstream languages.
RELATED WORK 7. 1 Analysis of the Redundancy Assumption The key assumption behind GenProg is that the patch reuses some code from elsewhere in the program, this is called the redundancy assumption. Previous works have investigated this assumption. Barr et al. [2]  and Martinez et al. [29]  studied the assumption behind GenProg  [18] : patches are synthesized using fragments of code already written in the program under repair. Those works measured the redundancy of a commit: for each commit, the redundancy is the percentage of code introduced that was already introduced by a previous commit. Our approach is different, we verify that a single commit lies in the search space of a repair system. Note that our post-matching rules also verifies the redundancy of the introduced code for the repair actions that are based on the redundancy assumption.
Mining Bug-fix Patterns from Bug Datasets Sobreira et al. [38]  manually analyzed 395 ground-truth patches of Defects4J  [14]  buggy programs. They first identified abstractions, called repair patterns, occurring recurrently in patches and involving compositions of repair actions. They identified nine repair patterns from the patches in Defects4J, which span 373 patches of the dataset (94. 43%). Madeiral et al. [23]  presented PDD, a detector of repair patterns in patches. PDD performs source code change analysis at abstract syntax tree level and is able to detect the patterns found in Defects4J. PDD and our work have important differences. First, they focus on a repair patterns that capture human-made changes, while we focus on on repair patterns that characterize automated fixes from program repair systems.
Mining Instances of Code Changes There are different works that inspect bug-fix commits and patches with the goal of characterizing the bug-fixing activity. Pan et al. [32]  built a catalog with 27 bug-fix patterns that they manually identified by inspecting the history of seven open-source Java projects. Then, they build a tool for detecting instances of such bug-fix patterns. They finally reported the frequency of each bug-fix pattern. Other works have mined Pan's pattern instances from other datasets. Campos and Maia  [3]  measured the prevalence of the five most common bug-fix patterns from  [32]. For this purpose, they queried the Boa dataset  [8]  to find how many of the 4, 590, 405 included commits follow each pattern. Islam and Zibran  [12]  have mined instances of 21 Pan's pattern from bug-fix commits done on 5 Java systems.
Soto and Le Goues  [39]  created one of such probabilistic models of edit distributions that was used by a repair system to repair faster. For that, the authors mined repair operators from bug-fixes done on the 500 most-starred Java projects on Github. They encoded 19 operators in total, selected from those defined by GenProg  [18] , PAR  [15] , SPR  [20]  and three additional PAR templates. Ghanbari et al. [10]  have mined real bug-fix patches from the HDRepair dataset  [16]  to measure the frequency of their repair operators implemented in their approach PraPR. Their goal was to further confirm the generality of the 18 PraPR mutators. The PraPR's "MR mutator", which mutates method invocation instructions, is the most frequent operator: it appeared in 8. 76% of the bug-fix patches for the HDRepair dataset.
Analysis of the Patch Search Space Weimer et al. [42]  presented AE, a repair approach that is specifically designed for optimizing the search space, using a cost model and multiple optimizations. For the evaluation of AE, the authors measured the size of the search spaces of AE and GenProg  [17]. Our analysis is different, we do not measure the size of search spaces, we measure the inclusion of real past commits in those search spaces. Long and Rinard  [21]  presented a systematic analysis of the SPR  [20]  and Prophet  [22]  patch search spaces. With respect to our paper, the most related contribution of  [20]  are that they analyze the density of correct and plausible patches in the search space, and they characterize a trade-off between the size and sophistication of the search space. Our approach has a different goal, we do not analyze plausibility, we analyze past commits from repositories to assess applicability of program repair.
CONCLUSION In this paper, we have presented the original concept of measuring the applicability of program repair systems on past commits. Our approach is based on static analysis of code changes and is implemented in RSCommitDetector. Using RSCommitDetector, we conduct an experiment on 41, 612 commits from 72 Github projects. We found that 1. 77% of the commits lie in the search space of at least one of the eight considered program repair systems. Our tool is reliable, it has a precision and recall of 77% and 92%, respectively. This paves the way to collecting large datasets of human-made commits which could have likely been made by repair systems. Such datasets are valuable for important research directions in program repair, such as data-driven tuning of program repair systems  [22]  or training neural networks to generate commit messages for program repair patches  [13, 31].
Thus, the full stream and background model is described by six parameters: r f f b f f b f f b f f f f f = + + + - -F I S , e xp exp exp 1 2 exp. 1 1 2 0 1 2 1 1 2 2 2 1 1 1 2 1 1 2 ⎜ ⎟ ⎡ ⎣ ⎢ ⎛ ⎝ ⎞ ⎠ ⎤ ⎦ ⎥ ( ) [ ( ) ( ) ( )] [ ( )] ( ) [ ( )] ( ) In this equation, β 0 , β 1 , and β 2 represent the normalization, slope, and quadratic term of the log-background, while Φ 2 , S, and I represent the stream track, the stream width, and the linear stream density, respectively. We implement this model in the STAN programming language, which is specialized for statistical modeling and provides an easy interface to specify and efficiently sample probabilistic models  (Carpenter et al. 2017). The posterior distributions of the model parameters given the Phoenix data are sampled using the No-U-Turn Sampler version of the Hamilton Monte Carlo technique, which is useful for exploring high-dimensional parameter spaces efficiently  (Hoffman & Gelman 2011; Neal 2011, pp.
Distance Gradient The improved quality and depth of the DES Y6 data allow us to measure the distance and distance gradient of the Phoenix 59 http://github. com/SheffieldML/GPyOpt 60 We note that we limit our possible number of nodes to between 5 and 30 for the stream track, density, and background; between 3 and 30 for the width; between 3 and 20 for the slope of the log-background; and between 3 and 10 for the quadratic term of the log-background. stream more accurately than was possible with the DES Y1 data analyzed by  Balbinot et al. (2016). To measure the distance gradient, we scan our isochrone selection in distance modulus from 14. 5 m -M 18. 0 in steps of 0. 01 mag. At each step in distance modulus, we count the number of stars on the stream track passing the isochrone selection and create a 2D histogram of those stars as a function of distance modulus and f 1.
Orbit Model We run a model of the dynamical evolution of the Phoenix stream to simulate the final debris seen in the data today and provide updated orbit parameters for the stream. To do this, we use the modified Lagrange Cloud Stripping technique from  Gibbons et al. (2014) , in which particles are stripped at the Lagrange points of the progenitor and evolved forward in the joint potential of the progenitor, Milky Way, and Large Magellanic Cloud (LMC). We model the Milky Way potential using the results of  McMillan (2017) , and we evaluate the potential using the galpot code  (Dehnen & Binney 1998). 61 s in  Shipp et al. (2021) , we sample the MCMC chains from the McMillan (2017) fit and use the lowest-mass realization, with M MW = 8. 3 × 10 11 M e. We include the LMC, modeled as a spherical Hernquist profile  (Hernquist 1990) , embedded with a Miyamoto-Nagai disk  (Miyamoto & Nagai 1975).