I analysed 185 papers papers citing GAP, published in 2014-2015 and contained in MathSciNet as on August 18th, 2015. The diagram below (click on the picture to enlarge) shows the number of papers citing GAP releases by the year of the release. It also shows releases that were published (though not necessary cited in the analysed papers) in corresponding years.

Some facts discovered:

• 44% (81 paper) refer to GAP 4.5.4 (the 1st public release of GAP 4.5 in June 2012) or some newer version.
• 24% (44 papers) cite GAP 4.4.12 (December 2008), which was the stable GAP release for several years until the appearance of GAP 4.5.
• 14 papers cite some GAP package but not GAP, so this only gives some hints to the version of GAP that might be used.
• 9 papers cite GAP without GAP version and/or release year.
• 19% (35 papers) cite GAP 4 releases published during 2000-2007.
• 1 paper genuinely cites GAP 3.4.4 because it uses the CHEVIE package.

It is not surprising that there is a long tail of citations of older versions. Papers that appeared in 2014 may be submitted prior to GAP 4.5 release, or, even if they were submitted after, describe experiments that were performed using GAP 4.4.12. But it is interesting what’s behind those 35 citations of the older GAP releases. Are these real usages of outdated GAP installations, re-used bibliographies from earlier papers, or something else?

Specifying the exact version of the system (as well as specific GAP packages, if their use was essential) is very important for the reproducibility of computational results. Furthermore, each GAP release contains new features and bugfixes, and comes with updated and expended set of GAP packages (see the history of GAP releases). Therefore, we suggest to always try to use the latest release, and to cite it correctly (GAP function Cite may help with that).

1. Use command line for object exploration and prototyping, then write the proper code.
2. Use LogTo to save inputs and outputs to a logfile which then you can edit in a text editor.
3. Save code in text files and use Read to load them. Find some advanced text editor to edit these files.
4. Make your code modular and reusable by organising it into functions.
5. Write comments in the code – this will help you when you will return to it after a while.
6. Use command line history instead of retyping commands! It even could be made available in the next GAP session.
7. Understand break loops: you may explore variables on the current break level and use Where to show the last commands before the error occurred.
8. Use preferences mechanism to customise GAP.
9. Understand the theory behind calculations: theoretical improvements could improve the performance much more than optimised code for brute-force calculations.
10. Cite GAP if you use it! This helps for the community to grow, and this will help you.

See also my earlier posts on things you may want to do after GAP installation and first steps in GAP.