The speaker said that SciPy uses Boost Python. My comment here was that it does not. I said nothing about SciPy's performance. I didn't say that my co-worker

The speaker said that SciPy uses Boost Python. My comment here was that it does not. I said nothing about SciPy's performance. I didn't say that my co-worker was the first to compute the derivatives. I said that it wasn't that complex of a task. Mark Nelson worked out by hand the second derivatives for the force fields and implemented them in NAMD (note: NAMD is not VMD). He also checked it against a couple of other implementations, including the one in XPLOR. I think he also checked against PMD and YAMD, and I believe he noticed that the PMD implementation was copied from XPLOR. My point is that it's not hard to find these manually. In any case there's little need to figure it out from scratch since nowadays the force-fields are available in code with a permissive license, and the math available in publications like https://books.google.com/books?id=GYTuCAAAQBAJ&pg=PA168&lpg=PA168&dq=automatic+differentiation+%22force+field%22&source=bl&ots=G61DuaDKJw&sig=ho9GFl30kOUoqCrej8HXUXHzSDI&hl=sv&sa=X&ei=XYCJVcrML8LlywPWvLrAAQ&ved=0CC0Q6AEwAQ#v=onepage&q=automatic%20differentiation%20%22force%20field%22&f=false https://books.google.com/books?id=GYTuCAAAQBAJ&pg=PA168&lpg=... . It can make sense to develop new tooling to generate code automatically. The result might be faster than manual code, but as we heard, the auto-generated code is currently 10% slower than manual code. Or it might make sense when developing many different types of force fields, like what Konrad Hinsen does in ScientificPython (see http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.97.9462&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.97.... ). However, I heard nothing about developing new force fields, and in any case, parameterization is the limiting factor, not computing the second derivatives. My 'quibbles' are two-fold. The major one is that I heard or read 30+ years of history on how molecular modeling can be used to design solutions to real-world problems. The 1980s thought that it would be a CAD problem (which it wasn't). The late 1990s thought it was a simple matter of nanotech, with all sorts of designs for nifty diamond-based structures with no real-world hope. We've had special purpose programming languages for molecular modeling, custom computers with specialized networks, custom designed chips, GPU-based implementations, and more. There's no evidence that the limitation is in the tooling, which is a major part of the speaker's thesis. The minor one is that if someone makes minor mistakes that end up placing the speaker in a brighter light, and says them with confidence, then I believe it's reasonable to discount more the major points said with confidence which have less evidence, and which also place the speaker in a brighter light. What you see as quibbles for minor points I see as a way to judge how strongly the speaker is willing to trust personal beliefs over evidence and proof. (Yes, those personal beliefs might be right, but that's my previous point.)