Right now it can be a bit challenging to find one's way around in the code base; to figure out which recognition methods are there, and where to find them.
To a degree we try to address them with the manual chapter on recognition methods, which is partially generated from source by regen_doc.g.
But it can still be baffling to figure out which file contains what; and when adding new code, it is not so clear where to add it.
I think the subdirs generic, perm, matrix, projective are a good thing in this sense. But perhaps there should be further subdivisions and conventions. E.g. perhaps there should be way to quickly distinguish "leaf" code from "non-leaf" / "homomorphism" / "reduction" methods. And then possibly some more...
The example I have in mind here is $SL_n$ resp. $SL_2$ detection: we potentially have black-box and natural representation variants, and possibly also non-natural matrix group variants. It'd be nice if one could quickly tell which is what and where. E.g. if those were in
gap/generic/leaf/sl2.g
gap/projective/leaf/sl2.g
A more extensive example are alternating and symmetric groups, where we have black-box, permutation, and matrix methods. At least the following files deal with them:
gap/generic/SnAnUnknownDegree.gi
gap/perm/giant.gi
gap/projective/AnSnOnFDPM.gd
gap/projective/AnSnOnFDPM.gi
gap/SnAnBB.gi
and the file names are not exactly conductive to finding them (SnAn vs. AnSn vs. giant).
And in all those cases, what is also not clear is which of those do "naming", which do "constructive recognition", which perhaps do both? From the name one can't tell that one of the following two files handles naming, the other constructive recognition:
gap/matrix/classical.gi
gap/projective/classicalnatural.gi
Perhaps that suggests three kinds of further subdirs below each of generic/perm/matrix/projective:
naming (necessarily naming applies to leaves)leafnonleaf or homom or reduction or so
And yes, that may also mean that we split up some files which currently contain both kinds of methods (I think that's in fact useful for finding things)
Then we would have
gap/matrix/naming/classical.gi
gap/projective/leaf/classicalnatural.gi
Right now it can be a bit challenging to find one's way around in the code base; to figure out which recognition methods are there, and where to find them.
To a degree we try to address them with the manual chapter on recognition methods, which is partially generated from source by
regen_doc.g.But it can still be baffling to figure out which file contains what; and when adding new code, it is not so clear where to add it.
I think the subdirs
generic,perm,matrix,projectiveare a good thing in this sense. But perhaps there should be further subdivisions and conventions. E.g. perhaps there should be way to quickly distinguish "leaf" code from "non-leaf" / "homomorphism" / "reduction" methods. And then possibly some more...The example I have in mind here is$SL_n$ resp. $SL_2$ detection: we potentially have black-box and natural representation variants, and possibly also non-natural matrix group variants. It'd be nice if one could quickly tell which is what and where. E.g. if those were in
A more extensive example are alternating and symmetric groups, where we have black-box, permutation, and matrix methods. At least the following files deal with them:
and the file names are not exactly conductive to finding them (
SnAnvs.AnSnvs.giant).And in all those cases, what is also not clear is which of those do "naming", which do "constructive recognition", which perhaps do both? From the name one can't tell that one of the following two files handles naming, the other constructive recognition:
Perhaps that suggests three kinds of further subdirs below each of generic/perm/matrix/projective:
naming(necessarily naming applies to leaves)leafnonleaforhomomorreductionor soAnd yes, that may also mean that we split up some files which currently contain both kinds of methods (I think that's in fact useful for finding things)
Then we would have