ufuzz failure #5215
Comments
|
@kzc this one's simpler than #5212 − no rest syntax required: $ node -v
v6.17.1
$ echo '(({[[] = []]: a}) => console.log("PASS"))(0);' | node
PASS
$$ node -v
v8.17.0
$ echo '(({[[] = []]: a}) => console.log("PASS"))(0);' | node
$$ node -v
v10.24.1
$ echo '(({[[] = []]: a}) => console.log("PASS"))(0);' | node
PASS
$Seems to be a parser bug, since a pair of braces would mask it: $ node -v
v8.17.0
$ echo '{ (({[[] = []]: a}) => console.log("PASS"))(0); }' | node
PASS
$ echo '(({[[] = []]: a}) => { console.log("PASS") })(0);' | node
PASSCurrent mystery for me: this bug seems to be popping up more frequently on |
prng not so random? |
I sincerely hope not − it's not like we casually spam Lines 373 to 376 in 57a9519 and if not, then I hope nobody is using GitHub Actions to generate key pairs❗😅 |
|
This shows that prng distribution looks pretty uniform - on my machine at least... --- a/test/ufuzz/index.js
+++ b/test/ufuzz/index.js
@@ -11,2 +11,6 @@ var UglifyJS = require("../..");
var randomBytes = require("crypto").randomBytes;
+
+for (var i = 0; i < 1e6; i++) console.log(rng(19));
+process.exit(0);
+
var sandbox = require("../sandbox"); |
|
Good to know − although if we have a problem with the initial seed, or if there is non-uniformity in n-grams distribution, then we will still experience uneven/clustered test cases while displaying perfect first-order uniformity. |
|
Yeah, I ran it twice to demonstrate that the initial seed was different - which it obviously would have to be to generate unique test cases at all. No measure of the quality of the entropy though. I assume if that program were to be run on the github cluster it'd also produce a uniform distribution. But it might be worth verifying. |
Ah of course − sorry for the thinko 😅
What I've observed so far is that the same type of false positives tend to happen in clusters, temporally speaking. The test requires to show definitive results is probably rather prohibitive in size − and even assuming such deficiencies, |
|
Beyond the prng algorithm, I don't think independent node processes on the same machines or different machines share any state. Conceivably a new node patch release could be used by github CI that introduced a bug. Then there's always this possibility: |
OT: I've got curious about that, so I tried to derive the formula for it − but I've got 38.5% instead: <!doctype html>
<html>
<head>
<title>Probability of r heads or more in a row for n flips</title>
</head>
<body>
r = <input id=r type=text value=10 />
<br />
n = <input id=n type=text value=1000 />
<br />
P(n, r) = <input id=P type=text size=30 />
<button onclick="document.all.P.value=calc(1*document.all.n.value,1*document.all.r.value)">Calculate</button>
<script>
var cache = [];
function calc(n, r) {
if (n < r) return 0;
var ans = cache[r];
if (!ans) ans = cache[r] = [];
if (!(n in ans)) {
var p = 2 + n - r;
for (var q = 0, l = 2 * r; l < n; l++) {
q += calc(l - r, r);
}
ans[n] = (p - q) * Math.pow(2, -r - 1);
}
return ans[n];
}
</script>
<br />
Q(n, r) = <input id=Q type=text size=30 />
<button onclick="simulate(document.all.Q,1*document.all.n.value,1*document.all.r.value)">Simulate</button>
<script>
var tid;
function simulate(el, n, r) {
clearInterval(tid);
var count = 0, hit = 0;
var rounds = 10000;
// calibrate update interval
var start = Date.now();
test(rounds);
rounds = Math.ceil(rounds * 500 / (Date.now() - start));
tid = setInterval(function () {
test(rounds);
el.value = hit / count;
}, 1);
function test(rounds) {
while (--rounds >= 0) {
count++;
for (var i = 0, j = 0; i < n; i++) {
if (Math.random() < 0.5) {
j = 0;
} else if (++j == r) {
hit++;
break;
}
}
}
}
}
</script>
</body>
</html> |
My independently written program agrees with your result: To exceed 62% you need to flip 2000 coins per trial: |
|
Although the assertion in the linked blog was likely wrong or the problem was misstated, I think the point that clustering is not uncommon with random data is valid. |
|
So the real reason for these false positives popping up is because prior to d2e7c4a |
|
It makes perfect sense in hindsight. Good you got to the bottom of that. Do you plan to change ufuzz to not generate a non-compliant rest parameter? |
|
Thanks to you for discovering those
Not really − my plan is to teach |
The text was updated successfully, but these errors were encountered: