i'm at a loss of words after reading a paper about reformatting code using an ML model that has a measured statistical quantity A_c which says how often the reformatted code behaves the same as the original
-
@whitequark i can imagine a few cases where reformatting a code could change behavior (mostly related to language constructs that capture source locations) so I think I would be willing to accept as low as 99.99%
@porglezomp you'll love Fig. 6
-
i'm at a loss of words after reading a paper about reformatting code using an ML model that has a measured statistical quantity A_c which says how often the reformatted code behaves the same as the original
the "ideal" (their choice of words) case is 64.2%
this isn't satire, this is real research published by IEEE/ACM
-
@porglezomp you'll love Fig. 6
@porglezomp there's explanatory text that says the issue with the identifier "found" is that it's rarely used
-
i'm at a loss of words after reading a paper about reformatting code using an ML model that has a measured statistical quantity A_c which says how often the reformatted code behaves the same as the original
the "ideal" (their choice of words) case is 64.2%
@whitequark “surely it just means differing output structure to accommodate the formatting, right?”
No, it just produces code that won’t compile. In a refactoring tool.
(Haha, didn’t see the post a minute before mine with the exact same snip)
-
i'm at a loss of words after reading a paper about reformatting code using an ML model that has a measured statistical quantity A_c which says how often the reformatted code behaves the same as the original
the "ideal" (their choice of words) case is 64.2%
@whitequark Huh. Were they actually trying to make it work, or trying to show that it's a bad idea to try to use ML for that task?
-
@whitequark Huh. Were they actually trying to make it work, or trying to show that it's a bad idea to try to use ML for that task?
-
@porglezomp there's explanatory text that says the issue with the identifier "found" is that it's rarely used
@whitequark I really love “not changing endl to \n” listed as a style issue when that changes buffer flushing behavior.
-
@whitequark I really love “not changing endl to \n” listed as a style issue when that changes buffer flushing behavior.
@porglezomp did you notice that one of the
Iftokens is capitalized in the output -
@porglezomp did you notice that one of the
Iftokens is capitalized in the output@whitequark hahaha I did not
-
@porglezomp you'll love Fig. 6
@whitequark @porglezomp I'm spitting out my drink at j++ → j--. Holy shit.
-
i'm at a loss of words after reading a paper about reformatting code using an ML model that has a measured statistical quantity A_c which says how often the reformatted code behaves the same as the original
the "ideal" (their choice of words) case is 64.2%
@whitequark you know where there's a ready source of additional words? you surely will not regret sourcing additional words.
-
i'm at a loss of words after reading a paper about reformatting code using an ML model that has a measured statistical quantity A_c which says how often the reformatted code behaves the same as the original
the "ideal" (their choice of words) case is 64.2%
Got a link? -
Got a link?
-
i'm at a loss of words after reading a paper about reformatting code using an ML model that has a measured statistical quantity A_c which says how often the reformatted code behaves the same as the original
the "ideal" (their choice of words) case is 64.2%
@whitequark not a paper *deliberately* about genetic algorithms, then?
-
i'm at a loss of words after reading a paper about reformatting code using an ML model that has a measured statistical quantity A_c which says how often the reformatted code behaves the same as the original
the "ideal" (their choice of words) case is 64.2%
@whitequark "Code style generally does not interfere
with the code semantics and executability"; but we present novel methods for it to do so! -
this isn't satire, this is real research published by IEEE/ACM
@whitequark So let me get this straight, IEEE thinks you should count it as a win if rewriting your code by vibing it has less than 15% better odds than a literal coinflip of reproducibility?
edited for clarity and to fix a typo
-
this isn't satire, this is real research published by IEEE/ACM
@whitequark @danlyke so … by "reformatted" I assume you mean aesthetically tidied up, with no change in functionality required?
If I got that right: wtf?
-
i'm at a loss of words after reading a paper about reformatting code using an ML model that has a measured statistical quantity A_c which says how often the reformatted code behaves the same as the original
the "ideal" (their choice of words) case is 64.2%
@whitequark compare and contrast the Extreme Programming philosophy, in which a code change doesn't count as "refactoring" unless all observable behavior is identical
-
@whitequark @danlyke so … by "reformatted" I assume you mean aesthetically tidied up, with no change in functionality required?
If I got that right: wtf?
-
i'm at a loss of words after reading a paper about reformatting code using an ML model that has a measured statistical quantity A_c which says how often the reformatted code behaves the same as the original
the "ideal" (their choice of words) case is 64.2%
@whitequark And this is how research money is lit on fire, I guess. Why else conduct research into ML for a task that has had obvious, deterministic, efficient and well-tested solutions for decades?
