Add SUM_FLAGS to Iterator for free groups #2857
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
wilfwilson
added
topic: library
backport-to-4.10
gapdays2018-fall
|
Let’s not fiddle around with this stuff at the moment |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In GAP
stable-4.10, the library method forIteratorfor a free group is sometimes replaced by a higher ranked method from theRCWApackage (in particular, when Alexander's tests doLoadAllPackages();and the method exists inrcwa-4.6.2/lib/rcwagrp.gi:2903). In GAPmaster, with the method ordering fixed, this doesn't happen; and in principle there is nothing wrong withRCWAinstalling a new method. However, it is causing problems for the Semigroups package (which can hopefully be resolved soon: see semigroups/Semigroups#532).In the first instance: is it sensible to add SUM_FLAGS to the library method for
Iteratorfor free groups? It seems to fit in with the philosophy of ranking representation-specific methods very highly. But since it's not directly causing any problems (apart from to the Semigroups package, but probably due to a bug), perhaps we should leave it alone.Your opinions are welcome.