5 ms·
I really don't think that it's easier to understand algorithm by reading its implementation than by reading its description. It's actually opposite -- frequentl
by xyzzyz 15y ago
I really don't think that it's easier to understand algorithm by reading its implementation than by reading its description. It's actually opposite -- frequently the idea behind algorithm is really hard to decipher if you only have access to code and not words. If you don't believe me, take an algorithm you don't know, read sample implementation (there are quite a lot on the internet these days) and try to understand how it works. I suggest trying KMP and Boyer-Moore for text matching, or Miller-Rabin and AKS for primality testing, or even RSA -- RSA is terribly simple in theory, but if you don't have a clue how it's supposed to achieve its goal, and you don't have background in number theory, then your chances of understanding it just by reading the code are infinitesimal.
- chime 15y agoWhy can't we have all three when relevant? Description + formulas + code? I understand why some algorithms (AKS, RSA) would not make sense if you just spit out the C code raw but I think it would make the paper much easier to understand if there was some code to go along with the formulas and descriptions, especially if the description is hard to decipher like "analyze the performance of the differencing algorithm on random instances by mapping it to a nonlinear rate equation."
- xyzzyz 15y agoIn most (if not all) papers I read there was already pseudocode, which is actually better than real programming language, because it lets you express your algorithm in a concise way without all the real world overhead, like initialization, allocation, etc. If you cannot implement algorithm yourself by reading its description and pseudocode, it means that either you don't fully understand what you just read, or your programming skills need some polishing, and you should be rather reading textbooks than research papers for a while. Also keep in mind that papers are written for the colleagues in the field to read, and not for the laymen, so it's no surprise that authors use the terminology familiar to people in the field. It makes no sense to write research papers with laymen in mind, because 99.999% of them don't care and the remaining 0.001% will learn terminology soon enough. Also, you really should not expect that reading research papers will be as easy as reading newspapers, don't you agree?
- KaeseEs 15y agoOftentimes, it is easy to overlook whether that real-world overhead affects the asymptotic performance of your algorithm in either an ideal sense or a pragmatic one. If memory allocation were free or memory were infinite, true constant time rather than amortized constant time push back on dynamic arays/vectors would be possible, etc. Also, initialization often affects correctness, so it's much less frequently skipped even in pseudocode for an algorithm.
- jedbrown 15y agoThere are some famous examples of tweaks that don't make the paper, but are actually critical to successful methods. Antony Jameson's aerodynamic codes are prime examples. He made good money for decades because Boeing and some other majors couldn't reproduce his code on their own, but his code gave better predictions compared to the wind tunnel, so they used it to design several generations of aircraft.
- william42 15y agoIf the code is that different from the paper, why was that paper published?
- jedbrown 15y agoReviewers don't get to see the code and most don't have the time or inclination to reimplement based on what is described in the paper to check whether it tells the whole story or not. Yes, this is different from a theorem which should come with a rigorous proof. This is a great talk on the subject: http://www.amath.washington.edu/~rjl/talks/LeVeque_CSE2011.pdf http://www.amath.washington.edu/~rjl/talks/LeVeque_CSE2011.p...