4 ms·
You have to dig really hard to find out what the specific problem was. It turns out this was the fix: def read_gaussian_outputfiles(): list_of_file
by nanis 7y ago
You have to dig really hard to find out what the specific problem was. It turns out this was the fix:
def read_gaussian_outputfiles():
list_of_files = []
for file in glob.glob('*.out'):
list_of_files.append(file)
list_of_files.sort()
return list_of_files
That is, the original code never sorted the files and instead it trusted that a simple `glob` would give it files sorted in whatever is the desirable way.
It is a reasonable mistake for a total noob to make (just like the hundreds of simulations which use the built-in `rand` function of whatever language they are using without even so much as mentioning this pertinent fact), this should be called a "programming error" instead of a "code glitch". Also, the error should be publicized up-front.
- mxcrossb 7y agoSo many comments in this thread are saying that scientists are bad programmers, but even a great programmer can make mistakes like this. The solution isn’t related to better programmers, but instead for users to treat codes as instruments, and hence a verification and calibration step.
- deleted 7y ago[deleted]
- fauigerzigerk 7y agoI would say it depends on the thought process that caused the bug. There are a couple of possibilities I can think of: Did the author of the code simply forget to sort? That's equally likely to happen to anyone. Did they assume that the sort order of glob.glob() was reliable across different OSs and file systems? I don't think this would have happened to an experienced software developer. At least there would have been enough doubt to go read the first line of the docs. Did they not care whether the code worked anywhere outside their own personal setup? This is perhaps slightly more likely in an academic environment but I'm not completely sure about that. We'd have to know more about the specific circumstances. What I find more astonishing is that it took so long for this bug to be found. It's not exactly an edge case or a rounding error. It must have caused wildly incorrect results in many cases. So I think the more important differences may be on an organizational level rather than a question of individual competence.
- zuzun 7y agoA reasonable mistake for all who already used the POSIX `glob` function, which returns sorted paths by default.
- Someone 7y agoHave you figured out, too, why this gives different results? I can easily imagine that it would affect rounding somewhere, but if so, neither of the numbers in the abstract (172,4, 172,7, 173,2, and again 173,2) is incorrect, and the relatively large range point towards numerical instability of the algorithm. Secondly, I would guess the reported difference between Mac OS Mavericks and Mac OS Mojave is because they tested on a Fusion Drive (I would expect the filesystem to cause the difference, and that changed with High Sierra, except for Fusion Drives, where it changed with Mojave)
- dr_zoidberg 7y agoSeeing the code, I don't get why this was encapsulated in a function, considering they don't even take a path argument. It could easily have been just a oneliner: gaussian_outputfils = sorted(glob.glob('*.out')) Of, if it needed function form: def read_gaussian_outputfiles(path): return sorted(glob.glob(f'{path}/*.out'))