Andy BuckleyFeb 20

Released #LHAPDF 6.5.6 today -- https://gitlab.com/hepcedar/lhapdf/-/releases/lhapdf-6.5.6

Since a colleague had a Claude Code sub, we asked them out of curiosity to get it to run a code review. This was actually pretty useful, and an indication of where #AI tools can help with stuff humans hate to do -- but using its solutions to help us think, _definitely_ not using its proposed solutions which would have definitely damaged quality and hidden (minor) issues.

...

LHAPDF 6.5.6 · Cedar / LHAPDF · GitLab

Various bugfixes and improvements, including speed-ups in the grid-indexing hot loop (thanks to Alexander Puck Neuwirth), efficiency improvements in the Fortran evolvepdfm and lhapdf_xfxq2_stdpartons functions (thanks to Alexander...

GitLab
Show threadAndy BuckleyFeb 20

There were no "realistic" bugs, but a couple of theoretical array overflows were worth fixing. One would have been hard to find because there was a good reason in principle for an offset and the comments referenced that reason... but it didn't apply to the partial copy we were using. So it just looked either more closely or usefully more naively than a developer review would.

...

Vidya Sagar VFeb 21
Show threadAndy Buckley

A second similar instance got me thinking about the algorithm (for quantile computation) a bit more carefully and now we have a smoothed version with more careful edge handling, rather than rounding to nearest integer in an asymmetric way.

I wouldn't have been looking at this code at all if the Claude review hadn't suggested there were hinky things in that block (which, admittedly, is in the less-used alternative calculation of a less popular PDF error formalism!)

...

Feb 20 at 11:27pmWeb
Show threadAndy BuckleyFeb 20

So overall, nothing big and there were also some false alarms in the report, but it was a handy thing that humans would hate to do. 8/10, would use again... but to inform expert developers, _definitely_ not to replace them!

/ends

Show threadBashStKidFeb 20
@agbuckley I like the soundbite “it can generate interesting questions, should never be allowed to provide undocumented answers”
Show threadaoanlaFeb 21
@agbuckley I assume you normally run linters against releases - it would be interesting to see if they picked up the array overflows (in particular, since that's a thing C and Fortran linters look for specifically).
Show threadAndy BuckleyFeb 21

@aoanla Actually we don't. I reckon it would have found it, since the new array size was easily calculable from the copy... only humans would be fazed by the very plausible reason for the offset! Any recommendations for things like that we can put in CI in a useful way?

It's a good point that not all this is new. The presentation was nice, the issues a bit more general (though it was wrong about MPI ranks), but we could probably have found this a while back with more checks in our process