Add LINS to gap_packages

[enriqueartal]

There is a new package gap package LINS and the goal of this PR is to add it to gap_packages. There is another change (which is not essential): allow parallel computation, at least of each package. I wonder also if it would be interesting to add more packages, they are loaded only if needed.

I encountered an unsolved problem. I can use the package function LowIndexNormalSubs using libgap.function_factory. There are two entries: a group and a positive integer and the output is the list of all normal subgroups with index bounded by the integer if the option allSubgroups is true (default value); if false, only the subgroups with exact index are obtained and if it is the goal, it is much faster than obtaining the whole list and filtering. But I do not know how to pass an option using function_factory, and I do not know how to pass the group using libgap_eval.

📝 Checklist

• The title is concise and informative.
• The description explains in detail what this PR is about.
• I have linked a relevant issue or discussion.
• I have created tests covering the changes.
• I have updated the documentation and checked the documentation preview.

⌛ Dependencies

[github-actions]

Documentation preview for this PR (built with commit 6169d51; changes) is ready! 🎉
This preview will update shortly after each push to this PR.

[dimpase]

independent package can be built in parallel. With GAP packages interdependencies, one has to be more careful

[enriqueartal]

Thanks, should the label be changed?

[dimpase]

yes, please change the label

[enriqueartal]

Is there a reason for removing the positive review label?

[dimpase]

this happens automatically after a git push

[dimpase]

is the sage-devel message

enriqu...@gmail.com

I found a way to pass options to functions in gap (looking at the use of function_factory in permgroup.py); I guess it can be improved and I do not know how to make it more useful. I put an example. In LINS package there is a function called LowIndexNormalSubs; without options, applied to a group G and a number n, it gives all the normal subgroups of G of index at most n; if one is only interested in n-index subgroups one has to pass the option allSubgroups as false; if only these subgroups are needed it is much faster than computing all of them and filter. The following seams to work

low_index_normal_subgroups_exact = libgap.function_factory("""function(G, n) return LowIndexNormalSubs(G, n : allSubgroups := false); end; """)

relevant here?

[enriqueartal]

I think not directly. Till now I was unable to pass the option to this function in sage. I think it is not bad to have predefined sage functions for functions in gap, but I am not sure neither which ones nor how. Maybe it could be addressed in another PR.

[dimpase]

in a way, pre-defined GAP functions are there.
Namely, if foo(x,y) is a GAP function you want to pass already known to Sage objects, then
x.foo(y) is a valid Sage function.
As well as libgap.foo(x,y) is good, too.
(needless to say, it might be that in some cases one needs libgap(x) rather than x)

You can see this used quite a bit in e.g.
src/sage/graphs/generators/classical_geometries.py.

Thus, I am not sure what exactly you are missing.

[slel]

This contribution added two files Pipfile and src/Pipfile.
These (autogenerated?) files used to be "git ignored" until #39031.
Should a followup "git remove" them and "git ignore" them again?
See also:

• Pipfile removal: Remove pipfile #39031
• sage-devel discussion: https://groups.google.com/g/sage-devel/c/QzbJBpYHWgI
• sage-devel search: https://groups.google.com/g/sage-devel/search?q=pipfile
• repo and issue tracker search for "pipfile": https://github.com/search?q=repo%253Asagemath%252Fsage+pipfile

[dimpase]

@enriqueartal - where these Pipfiles added by you here a mistake?
I thought this PR needs them. If not, we should just purge them.

[enriqueartal]

It is a mistake. I sincerely do not know why they are there. Since it is closed, should I do something?

[dimpase]

It is a mistake. I sincerely do not know why they are there.
from using git commit -a without carefully looking what files you are adding, I suppose

Since it is closed, should I do something?

@enriqueartal open a PR which removes them, I'll approve it straight away

[enriqueartal]

Done, I hope correctly. Sorry for the inconvenience