Closed mlesnick closed 7 years ago
mlesnick
commented
7 years ago Original comment by M L (GitHub: mlesnick):
Resolved in the GitHub repository in
commit 3e8f6405436fdce3d30347080327dbb5f61298cb
It seems that the old fixes to RIVET's thresholding scheme from June 7 were lost in some Merge. Matthew reintroduced them, as described in the commit notes on GitHub.
mlesnick
commented
7 years ago Original comment by M L (GitHub: mlesnick):
Adding a .pdf of the email exchange which discusses some of the changes that were made re: thresholding.
It seems that the bug may be related to differences between the fixes discussed in the email exchange and the fixes implemented.
Originally reported by: M L (GitHub: mlesnick)
Problem file attached.
With 20x20 bins, H0, it seems to be getting stuck at the computation of one of the first few barcode templates.
Last time we saw an issue like this, it was because of an issue with how we were estimating whether to do a reset/vs. vineyard update, which was then addressed. This seems to agin be the case. The relevant verbose -V 9 output is below
console: -->Did 382342 vineyard updates in 2558 milliseconds.
console: initial reset threshold set to 3972590
console: PROGRESS 0
console: step 0 of path: crossing (non-strict) anchor at ( 19 , 0 ) into cell 53 ; edge weight: 82839751
console: -- barcode: 0-->29 (101,244480)-->(29,32) (402,511408)-->(29,32) (512,276143)-->(29,32) (712,312549)-->(29,32) (942,464631)-->(29,32) (1065,464776)-->(29,32) (1111,493272)-->(29,32) (1351,532459)-->(29,32) (1465,558244)-->(29,32) (1475,558249)-->(29,32) (1986,648979)-->(29,32) (1997,647897)-->(29,32) (1999,651109)-->(29,32) (2186,686886)-->(29,32) (2209,688393)-->(29,32) (2231,690977)-->(29,32) (2238,692563)-->(29,32) (2318,692631)-->(29,32) (2326,692638)-->(29,32) (2330,692642)-->(29,32) (2340,702207)-->(29,32) (2343,702422)-->(29,32) (2386,702463)-->(29,32) (2425,702501)-->(29,32) (2426,702502)-->(29,32) (2429,711530)-->(29,32) (2434,711664)-->(29,32) (2491,713144)-->(29,32) (2497,714036)-->(29,32) (2499,711676)-->(29,32) (2510,714039)-->(29,32) (2522,714041)-->(29,32) (2528,712508)-->(29,32) (2534,717293)-->(29,32) (2535,1324277)-->(31,33) (2548,717412)-->(31,32) (2581,717416)-->(31,32) (2583,1324275)-->(31,33) (2585,718563)-->(31,32) (2587,3697841)-->(31,35) (2588,717597)-->(31,32) (2589,717586)-->(31,32) (2606,717664)-->(31,32) (2612,717604)-->(31,32) (2628,717588)-->(31,32) (2637,718466)-->(31,32) (2654,718543)-->(31,32) (2659,718472)-->(31,32) (2683,718589)-->(31,32) (2690,718637)-->(31,32) (2694,719171)-->(31,32) (2703,718973)-->(31,32) (2708,1901865)-->(31,34)
console: --> this step took 2 milliseconds and involved 0 transpositions; estimate was 0
console: -- new threshold: 9223372036854775808
console: PROGRESS 1
console: step 1 of path: crossing (non-strict) anchor at ( 18 , 0 ) into cell 52 ; edge weight: 76369671
console: -- barcode: 0-->27 (101,244480)-->(27,32) (402,511408)-->(27,32) (512,276143)-->(27,32) (712,312549)-->(27,32) (942,464631)-->(27,32) (1065,464776)-->(27,32) (1111,493272)-->(27,32) (1351,532459)-->(27,32) (1465,558244)-->(27,32) (1475,558249)-->(27,32) (1986,648979)-->(27,32) (1997,647897)-->(27,32) (1999,651109)-->(27,32) (2186,686886)-->(27,32) (2209,688393)-->(27,32) (2231,690977)-->(27,32) (2238,692563)-->(27,32) (2318,692631)-->(27,32) (2326,692638)-->(27,32) (2330,692642)-->(27,32) (2340,702207)-->(27,32) (2343,702422)-->(27,32) (2386,702463)-->(27,32) (2425,702501)-->(27,32) (2426,702502)-->(27,32) (2429,711530)-->(27,32) (2434,711664)-->(29,32) (2491,713144)-->(29,32) (2497,714036)-->(29,32) (2499,711676)-->(29,32) (2510,714039)-->(29,32) (2522,714041)-->(29,32) (2528,712508)-->(29,32) (2534,717293)-->(29,32) (2535,1324277)-->(31,33) (2548,717412)-->(31,32) (2581,717416)-->(31,32) (2583,1324275)-->(31,33) (2585,718563)-->(31,32) (2587,3697841)-->(31,35) (2588,717597)-->(31,32) (2589,717586)-->(31,32) (2606,717664)-->(31,32) (2612,717604)-->(31,32) (2628,717588)-->(31,32) (2637,718466)-->(31,32) (2654,718543)-->(31,32) (2659,718472)-->(31,32) (2683,718589)-->(31,32) (2690,718637)-->(31,32) (2694,719171)-->(31,32) (2703,718973)-->(31,32) (2708,1901865)-->(31,34)
console: --> this step took 2 milliseconds and involved 0 transpositions; estimate was 0
console: -- new threshold: 9223372036854775808
console: PROGRESS 2
console: step 2 of path: crossing (strict) anchor at ( 19 , 1 ) into cell 338 ; edge weight: 937722112
And here RIVET stops making progress...
If I remember correctly, for 0 transpositions, there should be no update to the threshold. So why is there an update now, creating an insanely large new threshold?
I wonder if RIVET is miscounting the number of transpositions here.