The judge's solution is initially set to be a legal contest submission. To see graphical output for all judge's data sets, you need to make two changes. In the judge's checking code at the end, initialize the variable hideGraphics to false and uncomment the first if statement in the method dataSetCheck. The alt subdirectory shows a solution with a different algorithm (rolling rather than falling).
With floating point arithmetic and complicated patterns in different algorithms it is notoriously difficult to ensure identical results with different (correct) algorithms. Three kinds of tests were made in the judge's solutions to be sure such problems were avoided.
If the solution is run set to generate summary statistics with the judge's input, the following is produced:
Overall minimums:
Roundoff Leeway: 0.000402; Circle Separation: 0.027864; Badness diff: 0.020083
1. Rounding to many fewer places than full double precision generally gives the same results to different implementations, but this fails if the actual value is too close to a transition between roundoff values. No answer was closer than 0.000402 to a value with a different rounded answer.
2. The entire topology of the solution can change based on numerical inaccuracies if one solution has a circle barely catching on two boundary points while another algorithm has it barely passing without catching. The closeness to this transition was noted for all calculations, and circles either caught or completely missed catching by at least 0.027864. This was further checked by adjusting the separations where a circle was declared to catch or not interfere with another. This was encoded in the variable OkSep, which mathematically should be 0, but it could be adjusted with a command line parameter. The program was run three times:
java falling > falling.out