3 ms·
This is the correct approach. We, the "software engineers", can jump in and help. If it eventually comes out that the results were wrong then the papers should
by emerongi 6y ago
This is the correct approach. We, the "software engineers", can jump in and help. If it eventually comes out that the results were wrong then the papers should be retracted. At the moment there is no proof of that.
That's the beauty of open-sourcing the code: people can help or verify. Needlessly shitting on other people's work without any proof is just disheartening to me.
- einszwei 6y agoI'm reminded of the idiom "Don't throw the baby out with the bathwater". And I agree that software engineers should more actively contribute their expertise here. With that said, if a research paper's main contribution is a model whose results were evaluated using a code with major bugs then retraction of the paper is only professional.
- acqq 6y ago> if a research paper's main contribution is a model whose results were evaluated using buggy code There's no proof of that at all in this case. The person complaining didn't find any scientifically valid problem, only that he personally for some not cleanly stated reason doesn't like the tests provided, which is clearly stupid. Since when should any tests be such that some random guy on github must like them? If the code was used by the experts, and they maybe even used it for years, who says that these experts are in any way obliged to publish all their logs of their use of that code (which doesn't have to even exist in publishable form)? Even if all that they possibly iteratively did for potentially years could be condensed to some tests, who says that it wouldn't take too long (as in, months, years) for that? It's practically just a matter of good will that the code is published at all, in any form at all.
- einszwei 6y agoApologies if my earlier comment came off as insinuating that code used for research paper was buggy. That was not my intent.