Some experimenting shows the following:
Applying W(-) to an element of the iterator is bad. In other words:
I.e.
R = libgap.RightTransversal(W,G)
for w in R:
v = W(w)
leads to some kind op corruption of R (which may manifest itself in
different ways). It is hard to imagine how that is possible. Perhaps the
element w keeps a reference to R which somehow gets corrupted when W(...)
is applied? That seems far fetched but I can't think of anything else. I
even tried to replace W by a copy (via WW=PermutationGroup(W.gens())) and
then to use WW(w) but that made no difference.
Converting R to a list eliminates the corruption. Even if one does it
manually. E.g. the following is fine.
L = []
for w in R:
L.append(w)
for w in L:
v = W(w)
Other variations of converting R to a list (e.g. using enumeration and
R[i]) all work fine,
To me it really looks like a Sage/Cython bug.
Best,
Michel
On Saturday, February 7, 2026 at 7:20:47 AM UTC+1 [email protected] wrote:
> As I explained on the GitHub issue,
> it's more nuanced than that: RightTransversal is not a list, it's a
> list-like object which need not behave as a real list.
>
> I don't know at the moment whether libgap (a library provided by the GAP
> project) is capable of advertising to the user of their API
> this fact, and how to find out what's safe to do with it, and what's not.
>
> I have asked for help here <https://github.com/gap-system/gap/issues/6223>
>
>
>
> On February 7, 2026 12:11:28 AM CST, 'Michel VAN DEN BERGH' via
> sage-support <[email protected]> wrote:
>
>> IMHO it's not clear yet it's a GAP bug. If you use
>> gap.RightTransversal(W,G) then there is no problem (but this is of course
>> much slower).
>>
>> The fact that gap.RightTransversal(W,G) and
>> list(libgap.RightTransversal(W,G)) both give the right thing suggest that
>> GAP certainly knows the correct answer and that something goes wrong with
>> forwarding it to Sage.
>>
>> So, unless further evidence to the contrary appears, my vote would be for
>> a bug in the Sage-GAP interface.
>>
>> Best,
>> MIchel
>>
>>
>>
>>
>>
>>
>>
>>
>> On Friday, February 6, 2026 at 11:03:14 PM UTC+1 [email protected] wrote:
>>
>>> might it make sense to ask the gap people for help?
>>>
>>> Martin
>>>
>>> On Friday, 6 February 2026 at 22:57:54 UTC+1 Martin R wrote:
>>>
>>>> I think that this is a very serious bug, if you are unlucky, you might
>>>> get wrong results without noticing.
>>>>
>>>> The failure in https://github.com/sagemath/sage/issues/33072 looks
>>>> somewhat similar.
>>>>
>>>> Unfortunately, I have no idea how to debug it.
>>>> On Friday, 6 February 2026 at 16:20:28 UTC+1 [email protected]
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thursday, February 5, 2026 at 6:39:18 PM UTC+1 dwrote:
>>>>>
>>>>> On Thu, Feb 5, 2026 at 9:59 AM 'Michel VAN DEN BERGH' via sage-support
>>>>>
>>>>> wrote:
>>>>> >
>>>>> > Ok here is the setting. It is rather specific.
>>>>> >
>>>>> > I have a group G (W(E8) in this example) and a left G equivariant
>>>>> equivalence relation R on it. R is not known directly, but for any g in G
>>>>> and any subset S of G I can efficiently check (complexity O(1)) if g is
>>>>> equivalent to any element in S. I want to find representatives for G/R.
>>>>> >
>>>>> > Of course this is equivalent to determining the subgroup H={h in G |
>>>>> h ~ 1} and a set of representatives for G/H.
>>>>> >
>>>>> > So what I do is I start with H={1}, S={1} and iterate over
>>>>> representatives of g of G/H. If g is not equivalent to any element in S
>>>>> then I add g to S.
>>>>> > If g is equivalent to an element s in S then h=g^-1 s ~ 1 and I
>>>>> replace H with the subgroup generated by H and h and repeat.
>>>>> >
>>>>> > The algorithm stops when |H| |S|=|G|. It works very efficiently, as
>>>>> long as G/R is not too big (even if G itself is big).
>>>>>
>>>>> Would it be more efficient to start from a subgroup G_1 of G and
>>>>> compute the analog of R in G_1, and the corresponding H_1, first?
>>>>> Then, for G and R, you can start with H=H_1, instead of H={1}, right?
>>>>>
>>>>>
>>>>> Perhaps. But in the case I looked at then H becomes bigger quickly. So
>>>>> starting with H={1} does not seem to be a problem.
>>>>>
>>>>>
>>>>> Anyway, as FactorCosetAction is pretty fast, one can re-do it once a
>>>>> new h to add to H is found.
>>>>> The question is how to relate points of the domain O of the
>>>>> permutation group f (where
>>>>> f=libgap(W).FactorCosetAction(libgap(G)).Image(),
>>>>> or, in the notation of this message,
>>>>> f=libgap(G).FactorCosetAction(libgap(H)).Image())
>>>>>
>>>>> Each point of O is obtained by applying a sequence of generators of G
>>>>> to 1 (i.e. to the coset {H}).
>>>>> Classically, such a sequence can be obtained from the Schreier vector
>>>>> (https://en.wikipedia.org/wiki/Schreier_vector). GAP itself does not
>>>>> give you a ready access to a Schreier vector for an orbit,
>>>>> but the GAP package orb has such a facility (
>>>>> libgap.LoadPackage("orb") will load it into the Sage session,
>>>>> and you need gap_packages spkg installed, or, if your Sage install
>>>>> uses system-wide GAP, you need it installed there).
>>>>> So you'll need to call Orb() from orb package with option ":
>>>>> schreier:=true" - this is something that has to be done via
>>>>> libgap.function_factory(). And then use
>>>>> TraceSchreierTreeForward (see
>>>>> https://docs.gap-system.org/pkg/orb/doc/chap3_mj.html#X7F927E787BA898BF)
>>>>>
>>>>> (or TraceSchreierTreeBack) to get the words.
>>>>> Or you can roll your own orbit algorithm where you'd record Schreier
>>>>> vector.
>>>>>
>>>>> Does this make sense?
>>>>>
>>>>>
>>>>> I think so. Thanks in any case for the very detailed explanation. I
>>>>> need to study it more carefully though. In any case RightTransversal(W,
>>>>> H)
>>>>> works fine except for the bug. But I have a reasonable workaround. I
>>>>> remember the cosets where the bug is triggered and once H no longer
>>>>> grows,
>>>>> I convert RightTransversal(W, H) to a list, to pick up the few cosets
>>>>> that
>>>>> were missed because of the bug.
>>>>>
>>>>> It is a mystery to me why list(RightTransversal(W, H)) does not suffer
>>>>> from the bug, but it is what it is...
>>>>>
>>>>> Best,
>>>>> Michel
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> HTH
>>>>> Dima
>>>>>
>>>>>
>>>>>
>>>>> >
>>>>> > Best,
>>>>> > Michel
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > On Thursday, February 5, 2026 at 4:33:15 PM UTC+1 wrote:
>>>>> >
>>>>> > In case you just want a permutation action of W on the cosets of G,
>>>>> you can avoid dealing with cosets all together.
>>>>> > sage: f=libgap(W).FactorCosetAction(libgap(G)).Image()
>>>>> > sage: f.OrbitLength(1)
>>>>> > 138240
>>>>> >
>>>>> > In fact, libgap(W).FactorCosetAction(libgap(G)) is a proper group
>>>>> homomorphism, so you can go back and forth between W and f.
>>>>> > If you explain what you wanted to do with your coset
>>>>> representatives, I can say more...
>>>>> >
>>>>> > Dima
>>>>> >
>>>>> > On Thursday, February 5, 2026 at 6:15:17 AM UTC-6 wrote:
>>>>> >
>>>>> > Hmm I have to retract this last post.Using
>>>>> >
>>>>> > for i in range(0, len(R)):
>>>>> > w = W(R[i])
>>>>> >
>>>>> > still triggers the bug.
>>>>> >
>>>>> > Best,
>>>>> > Michel
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > On Thursday, February 5, 2026 at 12:57:16 PM UTC+1 Michel VAN DEN
>>>>> BERGH wrote:
>>>>> >
>>>>> > On Thursday, February 5, 2026 at 12:15:21 PM UTC+1 wrote:
>>>>> >
>>>>> > As a workaround, I think that explicitly converting the gap list
>>>>> returned by libgap.RightTransversal(W, G) into a python list helps. I.e.,
>>>>> >
>>>>> > list(libgap.RightTransversal(W, G))
>>>>> >
>>>>> > Martin
>>>>> >
>>>>> >
>>>>> > I use this initially also for G=trivial (basically I am trying to
>>>>> incrementally build the stabilizer of something by iterating over the
>>>>> cosets of a stabilizing group already found) so constructing a list of
>>>>> which only a small part will be consumed is a bit inconvenient. However
>>>>> your issue suggests to use
>>>>> >
>>>>> > for i in range(0, len(R)):
>>>>> > w = W(R[i])
>>>>> >
>>>>> > This seems to work perfectly!
>>>>> >
>>>>> > I must say that I am mildly surprised that this works. I was
>>>>> guessing that the coset representatives would be found on the fly in some
>>>>> way.
>>>>> >
>>>>> > In any case: thanks for investigating and filing the issue!
>>>>> >
>>>>> > Best,
>>>>> > Michel
>>>>> >
>>>>> >
>>>>> > On Thursday, 5 February 2026 at 11:16:52 UTC+1 Martin R wrote:
>>>>> >
>>>>> > That's a huge example.
>>>>> >
>>>>> > sage: len(libgap.RightTransversal(W, G))
>>>>> > 138240
>>>>> >
>>>>> > I think it is a gap bug, I am checking right now.
>>>>> >
>>>>> >
>>>>> > On Thursday, 5 February 2026 at 07:46:47 UTC+1 wrote:
>>>>> >
>>>>> > > This is very strange code - you are attempting to change the
>>>>> variable of a loop inside a loop.
>>>>> > >
>>>>> > > What do you mean to do here?
>>>>> > >
>>>>> > > Dima
>>>>> >
>>>>> > Well that's not the point. Writing v=W(w) gives the same bug...
>>>>> >
>>>>> > Best,
>>>>> > Michel
>>>>> >
>>>>> > PS. This was just some quick test code, but this being said, I think
>>>>> assigning to a loop variable is fine. This does not influence the state
>>>>> of
>>>>> the iterator. A quick test confirms this.
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > --
>>>>> > You received this message because you are subscribed to the Google
>>>>> Groups "sage-support" group.
>>>>>
>>>>> > To unsubscribe from this group and stop receiving emails from it,
>>>>> send an email to.
>>>>>
>>>>> > To view this discussion visit
>>>>> https://groups.google.com/d/msgid/sage-support/2f5c40db-62ad-4e65-bfea-30f5e673ed39n%40googlegroups.com.
>>>>>
>>>>>
>>>>>
>>>>>
--
You received this message because you are subscribed to the Google Groups
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/sage-support/7f8a6903-cfae-4b67-aec3-8e43c67c1343n%40googlegroups.com.
