-
Notifications
You must be signed in to change notification settings - Fork 10
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
describe the pitfalls of NLP modeling
- Loading branch information
Showing
5 changed files
with
18 additions
and
6 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Binary file not shown.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,17 +1,19 @@ | ||
\chapter{\rm\bfseries Related Literature} | ||
\label{ch:litreview} | ||
|
||
Translating concepts into computer programs demands a high degree of precision, as computers have strict criteria for admitting valid programs. These constraints help eliminate meaningless programs and reduce runtime errors, but can be cumbersome to debug. During the process of programming, these constraints are inevitably violated, requiring typically manual repair. Automated repair attempts to suggest potential repairs from which the author may choose. This subject has been closely investigated in programming language research and treated in a number of existing literature reviews~\cite{monperrus2018living, le2021automatic}. We direct our attention primarily towards syntax repair, which attempts to repair parsing errors, the earliest stage in program analysis. | ||
Translating ideas into computer programs demands a high degree of precision, as computers have strict criteria for admitting valid programs. These constraints act as a failsafe against faulty programs and runtime errors, but can be tedious to debug. During the editing process, these constraints are invariably violated by the hasty or inexperienced programmer, requiring manual repair. To assist with this task, automated program repair (APR) attempts to generate possible revisions from which the author may choose. This subject has been closely investigated by programming language research and treated in a number of existing literature reviews~\cite{monperrus2018living, le2021automatic}. We direct our attention primarily towards syntax repair, which attempts to fix parsing errors, the earliest stage in program analysis. | ||
|
||
\section{Syntax Repair} | ||
|
||
Various strategies have been proposed to handle syntactic program errors, which have been a longstanding open problem since the advent of context-free languages. In 1972, Aho and Peterson~\cite{aho1972minimum} introduce an algorithm that returns a syntactically valid sequence whose distance from the original sequence is minimal. Their method guarantees that a valid repair will be found, but only selects one and does not produce every valid repair within the same distance. | ||
Spellchecking is an early precursor to syntax repair that originates from word processing and seeks to find, among a finite dictionary, the most likely intended revision of a misspelled word~\cite{kernighan1990spelling}. Akin to spellchecking, syntax repair considers the case where this dictionary is not necessarily finite, but rather generated by a grammar representing a potentially infinite collection of words called a language. In the case of programming language syntax, the language and corresponding grammar is typically context-free~\cite{chomsky1959algebraic}. | ||
|
||
While algorithmically elegant, this approach is problematic, because source code has both formal and natural characteristics. A pragmatic solution must not only suggest valid repairs, but also generate suggestions a human being is likely to write in practice. To model the natural distribution of valid programs, researchers have borrowed techniques from natural language processing to generate natural repairs. | ||
Various methods have been proposed to handle syntactic program errors, which have been a longstanding open problem since the advent of context-free languages. In 1972, Aho and Peterson~\cite{aho1972minimum} introduce an algorithm that returns a syntactically valid sequence whose distance from the original sequence is minimal. Their method guarantees that a valid repair will be found, but only generates a single repair and does attempt to optimize the naturalness of the generated solution. | ||
|
||
Recent work Yasunaga et al.~\cite{yasunaga2021break} and Sakkas et al.~\cite{sakkas2022seq2parse} use language models to sample probable fixes, but do not sample from the space of all valid repairs, and have difficulty with inference scaling, where additional test time samples are not . Furthermore, the generated samples are not all syntactically valid. | ||
While algorithmically elegant, this approach is problematic because source code has both formal and natural characteristics. A pragmatic solution must not merely suggest valid repairs, but also generate suggestions a human is likely to prefer in practice. To model coding conventions and stylistic patterns, researchers have borrowed techniques from natural language processing, but often sacrifice validity, precision or latency as these techniques are prone to misgeneralize and hallucinate syntactically invalid repairs. | ||
|
||
Our work addresses all these concerns. We try to generate all valid programs and prioritize them by naturalness, while ensuring that the latency and response time is minimal. In other words, we target soundness, completeness, naturalness and latency. | ||
Recent work Yasunaga et al.~\cite{yasunaga2021break} and Sakkas et al.~\cite{sakkas2022seq2parse} use natural language models to generate probable fixes, but do not attempt to sample from the space of all and only valid repairs. As a consequence, they have difficulty with inference scaling, where additional test time compute does not translate into improved precision. Furthermore, the generated samples may not even be syntactically valid, as we observe in practice. | ||
|
||
Our work addresses all of these concerns. We try to generate every nearby valid program and prioritize the solutions by naturalness, while ensuring response time is tolerable. In other words, we attempt to satisfy soundness, completeness, naturalness and latency simultaneously. | ||
|
||
|
||
\clearpage |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters