[sage-support] Re: Accessing group generators in libgap
Here is another question on libgap: Let some libgap elements be given; how to form the list of these elements in libgap? The purpose would, for example, be to create a group from that list. For instance: sage: G = gap.SmallGroup(48,36) sage: g1,g2,g3,g4,g5 = G.GeneratorsOfGroup() Since G is a polycyclic group, its generators look not very informative, but in any case they are valid elements in libgap: sage: g1*g2,g1*g2*g3,g4 (f1*f2, f1*f2*f3, f4) Nonetheless, the following doesn't work: sage: libgap.List(g1*g2,g1*g2*g3,g4) Traceback (most recent call last): ... ValueError: libGAP: Error, Variable: 'f1' must have a value What to do instead? Best regards, Simon -- 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 sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at https://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
[sage-support] Accessing group generators in libgap
Hi!
Define
sage: G = libgap.eval('Group([(3,4,5,6,7,8,9,10),(1,2)])')
(By the way, why does libgap.Group([(3,4,5,6,7,8,9,10),(1,2)]) not
work?)
In Gap, also in gap-via-pexpect, one can access the i-th generator of a
group (the count starts with 1) in the form G.i, but unfortunately this
doesn't work in libgap:
sage: G.1
Traceback (most recent call last):
...
AttributeError: name "gen" is not defined in GAP.
Explanation: Sage's preparser translates G.1 into G.gen(1), but libgap
doesn't know about gen. Apparently there is gap.gen defined, but not
libgap.gen.
(By the way: gap.gen?? behaves very strange, it shows the documentation
of chapter 7 entitled "Domains" of gap's documentation, and I need to
quit the viewer THREE TIMES to leave the documentation, and then I see
the documentation of the class GapFunction.)
Question 1: Is there an elegant way to access the first generator of G
than G.GeneratorsOfGroup()[0]?
Question 2: Do you think it would be a good idea to provide a libgap.gen
function, so that G.1 would return the first generator of G?
Best regards,
Simon
--
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 sage-support+unsubscr...@googlegroups.com.
To post to this group, send email to sage-support@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/d/optout.
[sage-support] Re: Problem with Sage's pexpect interface to Gap
Hi Dima, On 2018-09-29, Dima Pasechnik wrote: > How many (single) cosets are you talking about? > Once you have a permutation representation, these double coset > computations are very fast. > I am almost sure GAP first enumerates (single) cosets, anyway. There are 7 double cosets, but G.Order()/N.Order() is 170775. Best regards, Simon -- 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 sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at https://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
[sage-support] Re: Problem with Sage's pexpect interface to Gap
Hi Dima, On 2018-09-29, Dima Pasechnik wrote: > I believe making libGAP the default GAP interface is the way to go, and > much of the work needed for this conversion is already done... > > libgap's GAP objects are just thin cython wrappers around GAP's objects in > memory. > So you basically need to send to libgap a complete valid GAP statement > defining G. Sure. I was afraid that in some situations I'd need to convert from gap-pexpect to libgap (e.g., when unpickling cohomology rings that I've computed in the past). However, unpickling of gap stuff is done in a custom way anyway -- so, in my unpickling functions I could simply replace gap by libgap. It is some work, but hopefully worth-while to do. Best regards, Simon -- 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 sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at https://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
Re: [sage-support] Re: Problem with Sage's pexpect interface to Gap
On Sat, 29 Sep 2018, 10:32 Simon King, wrote:
> Hi Dima,
>
> On 2018-09-29, Dima Pasechnik wrote:
> > On Sat, Sep 29, 2018 at 9:58 AM Simon King
> wrote:
> >>
> >> On 2018-09-29, Simon King wrote:
> >> > Too bad: When the error occurs and I adjust the pool size then
> >> > afterwards the previously defined objects in gap are gone.
> >>
> >> Additional problem: Even when I increase the memory limit sufficiently,
> >> gap-via-pexpect takes substantially longer than libgap to compute the
> >> double cosets. Why is that? There shouldn't be big traffic in the
> >> interface whan just doing DC = G.DoubleCosetRepsAndSizes(N,N).
> >
> > Just use libGAP, perhaps?
> > (and do the port of the corresponding functionality to libGAP, if you
> have time)
>
> Rewriting my whole p_group_cohomology package to libGAP would be work
> that I'd rather avoid.
>
I believe making libGAP the default GAP interface is the way to go, and
much of the work needed for this conversion is already done...
> Given a group defined in gap-via-pexpect, how to put it into libGAP?
> Slight complication: My groups come with a name. Hence, the string
> representation of the group is not good, libGAP doesn't understand it:
>
> sage: G = gap.SymmetricGroup(6)
> sage: G.SetName('"G"')
> sage: libgap.eval(G)
> ...
> ValueError: libGAP: Error, Variable: 'G' must have a value
>
libgap's GAP objects are just thin cython wrappers around GAP's objects in
memory.
So you basically need to send to libgap a complete valid GAP statement
defining G.
> So, how can I make gap produce data that allow to reconstruct the group?
> Is libgap.Group(G.GeneratorsOfGroup()) the way to go? For permutation
> groups probably it is. But for polycyclic groups, as provided by the
> SmallGroups library?
> sage: G = gap.SmallGroup(720,761)
> sage: G
> Group( [ f1, f2, f3, f4, f5, f6, f7 ] )
> sage: libgap.Group(G.GeneratorsOfGroup())
> ...
> ValueError: libGAP: Error, Variable: 'f1' must have a value
>
> Concerning your hint to use the ACE package: After installing
> gap_packages, DC = G.DoubleCosetRepsAndSizes(N,N) takes a very long
> time in gap-via-pexpect (much longer than with libGAP), but so far it
> didn't crash. But it is VERY long. So, rewriting everything to
> libGAP might be the way to go after all. Sigh. Will be tedious work...
>
> Worse: It seems to me that after installing gap_packages, libgap takes
> long as well.
>
ACE is not in gap_packages AFAIK.
> Best regards,
> Simon
>
> --
> 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 sage-support+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-support@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-support.
> For more options, visit https://groups.google.com/d/optout.
>
--
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 sage-support+unsubscr...@googlegroups.com.
To post to this group, send email to sage-support@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/d/optout.
[sage-support] Re: Problem with Sage's pexpect interface to Gap
Hi Dima,
On 2018-09-29, Dima Pasechnik wrote:
> On Sat, Sep 29, 2018 at 9:58 AM Simon King wrote:
>>
>> On 2018-09-29, Simon King wrote:
>> > Too bad: When the error occurs and I adjust the pool size then
>> > afterwards the previously defined objects in gap are gone.
>>
>> Additional problem: Even when I increase the memory limit sufficiently,
>> gap-via-pexpect takes substantially longer than libgap to compute the
>> double cosets. Why is that? There shouldn't be big traffic in the
>> interface whan just doing DC = G.DoubleCosetRepsAndSizes(N,N).
>
> Just use libGAP, perhaps?
> (and do the port of the corresponding functionality to libGAP, if you have
> time)
Rewriting my whole p_group_cohomology package to libGAP would be work
that I'd rather avoid.
Given a group defined in gap-via-pexpect, how to put it into libGAP?
Slight complication: My groups come with a name. Hence, the string
representation of the group is not good, libGAP doesn't understand it:
sage: G = gap.SymmetricGroup(6)
sage: G.SetName('"G"')
sage: libgap.eval(G)
...
ValueError: libGAP: Error, Variable: 'G' must have a value
So, how can I make gap produce data that allow to reconstruct the group?
Is libgap.Group(G.GeneratorsOfGroup()) the way to go? For permutation
groups probably it is. But for polycyclic groups, as provided by the
SmallGroups library?
sage: G = gap.SmallGroup(720,761)
sage: G
Group( [ f1, f2, f3, f4, f5, f6, f7 ] )
sage: libgap.Group(G.GeneratorsOfGroup())
...
ValueError: libGAP: Error, Variable: 'f1' must have a value
Concerning your hint to use the ACE package: After installing
gap_packages, DC = G.DoubleCosetRepsAndSizes(N,N) takes a very long
time in gap-via-pexpect (much longer than with libGAP), but so far it
didn't crash. But it is VERY long. So, rewriting everything to
libGAP might be the way to go after all. Sigh. Will be tedious work...
Worse: It seems to me that after installing gap_packages, libgap takes
long as well.
Best regards,
Simon
--
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 sage-support+unsubscr...@googlegroups.com.
To post to this group, send email to sage-support@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-support] Re: Problem with Sage's pexpect interface to Gap
On Sat, Sep 29, 2018 at 10:09 AM Simon King wrote: > > Hi Dima, > > On 2018-09-29, Dima Pasechnik wrote: > > There is no real harm in doing > > set_gap_memory_pool_size(10*get_gap_memory_pool_size()) > > Yes, there is (see my other post). The computation takes much much > longer than in libgap. > > > If coset enumeration is the bottleneck, you should not use GAP's > > built-in one, by use the one in ACE GAP package, > > it is much faster and efficient with memory etc. > > Is ACE part of the gap_packages spkg? It's not ATM, but can and should be easily fixed. > If so: How to use its double coset > unumerator? Note that it is really about DOUBLE cosets. The cosets are > of no real use here. How many (single) cosets are you talking about? Once you have a permutation representation, these double coset computations are very fast. I am almost sure GAP first enumerates (single) cosets, anyway. > > Best regards, > Simon > > -- > 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 sage-support+unsubscr...@googlegroups.com. > To post to this group, send email to sage-support@googlegroups.com. > Visit this group at https://groups.google.com/group/sage-support. > For more options, visit https://groups.google.com/d/optout. -- 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 sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at https://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
[sage-support] Re: Problem with Sage's pexpect interface to Gap
Hi Dima, On 2018-09-29, Dima Pasechnik wrote: > There is no real harm in doing > set_gap_memory_pool_size(10*get_gap_memory_pool_size()) Yes, there is (see my other post). The computation takes much much longer than in libgap. > If coset enumeration is the bottleneck, you should not use GAP's > built-in one, by use the one in ACE GAP package, > it is much faster and efficient with memory etc. Is ACE part of the gap_packages spkg? If so: How to use its double coset unumerator? Note that it is really about DOUBLE cosets. The cosets are of no real use here. Best regards, Simon -- 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 sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at https://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
Re: [sage-support] Re: Problem with Sage's pexpect interface to Gap
On Sat, Sep 29, 2018 at 9:58 AM Simon King wrote: > > On 2018-09-29, Simon King wrote: > > Too bad: When the error occurs and I adjust the pool size then > > afterwards the previously defined objects in gap are gone. > > Additional problem: Even when I increase the memory limit sufficiently, > gap-via-pexpect takes substantially longer than libgap to compute the > double cosets. Why is that? There shouldn't be big traffic in the > interface whan just doing DC = G.DoubleCosetRepsAndSizes(N,N). Just use libGAP, perhaps? (and do the port of the corresponding functionality to libGAP, if you have time) > > Cheers, > Simon > > -- > 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 sage-support+unsubscr...@googlegroups.com. > To post to this group, send email to sage-support@googlegroups.com. > Visit this group at https://groups.google.com/group/sage-support. > For more options, visit https://groups.google.com/d/optout. -- 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 sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at https://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
[sage-support] Re: Problem with Sage's pexpect interface to Gap
On 2018-09-29, Simon King wrote: > Too bad: When the error occurs and I adjust the pool size then > afterwards the previously defined objects in gap are gone. Additional problem: Even when I increase the memory limit sufficiently, gap-via-pexpect takes substantially longer than libgap to compute the double cosets. Why is that? There shouldn't be big traffic in the interface whan just doing DC = G.DoubleCosetRepsAndSizes(N,N). Cheers, Simon -- 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 sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at https://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
Re: [sage-support] Re: Problem with Sage's pexpect interface to Gap
On Sat, Sep 29, 2018 at 9:46 AM Simon King wrote: > > Hi Dima, > > On 2018-09-29, Simon King wrote: > > Anyway, using set_gap_memory_pool_size(2*get_gap_memory_pool_size()) > > till everything works sounds like a reasonable way out. > > Too bad: When the error occurs and I adjust the pool size then > afterwards the previously defined objects in gap are gone. > > So, is it possible to adjust the pool size dynamically *without* the > need to repeat all computations in Gap from scratch? no, this is by design of GAP. There is no real harm in doing set_gap_memory_pool_size(10*get_gap_memory_pool_size()) as you are limiting maximal memory, not the initial memory allocated for GAP - at worst your Sage crashes... If coset enumeration is the bottleneck, you should not use GAP's built-in one, by use the one in ACE GAP package, it is much faster and efficient with memory etc. HTH Dima > > Best regards, > Simon > > -- > 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 sage-support+unsubscr...@googlegroups.com. > To post to this group, send email to sage-support@googlegroups.com. > Visit this group at https://groups.google.com/group/sage-support. > For more options, visit https://groups.google.com/d/optout. -- 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 sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at https://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
[sage-support] Re: Problem with Sage's pexpect interface to Gap
Hi Dima, On 2018-09-29, Simon King wrote: > Anyway, using set_gap_memory_pool_size(2*get_gap_memory_pool_size()) > till everything works sounds like a reasonable way out. Too bad: When the error occurs and I adjust the pool size then afterwards the previously defined objects in gap are gone. So, is it possible to adjust the pool size dynamically *without* the need to repeat all computations in Gap from scratch? Best regards, Simon -- 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 sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at https://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
Re: [sage-support] Re: Problem with Sage's pexpect interface to Gap
On Sat, Sep 29, 2018 at 9:19 AM Simon King wrote: > > Hi Dima, > > On 2018-09-29, Dima Pasechnik wrote: > > set_gap_memory_pool_size() > > controls the amount of memory GAP and libGAP get if started from Sage. > > The latter is dynamic, as opposed to "sage --gap" > > Do I understand correctly: libgap has dynamic pool size, but > gap-via-pexpect has not? both use the same controls involving t_gap_memory_pool_size - why it's slightly different I don't know, perhaps one can find out by reading code... > That would explain why libgap can do what > gap-via-pexpect can't. But why does my computation work in "sage -gap", > but not in gap-via-pexpect? > > Anyway, using set_gap_memory_pool_size(2*get_gap_memory_pool_size()) > till everything works sounds like a reasonable way out. > > Thanks and best regards, > Simon > > -- > 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 sage-support+unsubscr...@googlegroups.com. > To post to this group, send email to sage-support@googlegroups.com. > Visit this group at https://groups.google.com/group/sage-support. > For more options, visit https://groups.google.com/d/optout. -- 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 sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at https://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
[sage-support] Re: Problem with Sage's pexpect interface to Gap
Hi Dima, On 2018-09-29, Dima Pasechnik wrote: > set_gap_memory_pool_size() > controls the amount of memory GAP and libGAP get if started from Sage. > The latter is dynamic, as opposed to "sage --gap" Do I understand correctly: libgap has dynamic pool size, but gap-via-pexpect has not? That would explain why libgap can do what gap-via-pexpect can't. But why does my computation work in "sage -gap", but not in gap-via-pexpect? Anyway, using set_gap_memory_pool_size(2*get_gap_memory_pool_size()) till everything works sounds like a reasonable way out. Thanks and best regards, Simon -- 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 sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at https://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
[sage-support] Re: Problem with Sage's pexpect interface to Gap
PS:
I just found that libgap is able to compute the double coset
representatives, whereas gap-via-pexpect isn't. So, this might be a way
out, in the sense that I would need to change many lines of code from
gap to libgap, which is not just copy-and-paste, since apparently
gap('foo') corresponds to libgap.eval('foo'), not to libgap('foo').
My preferred solution, however, would be to enable gap-via-pexpect. How?
Best regards,
Simon
On 2018-09-29, Simon King wrote:
> Hi!
>
> Let G be the third Conway group, S its Sylow 2-subgroup, and
> N the normaliser of the centre of S in G.
>
> Gap is able to compute the list of double coset representatives of N in
> G using the command
> gap> DC := DoubleCosetRepsAndSizes(G,N,N);;
> gap> Length(DC);
> 7
> Actually, if I understand correctly, DC is not a list but an iterator,
> but for a list of size 7 this shouldn't matter so much.
>
> Anyway. If I do the above computation in the Sage pexpect interface to
> gap, the line
> DC = G.DoubleCosetRepsAndSizes(N,N)
> gives an error:
> RuntimeError: Gap produced error output
> Error, reached the pre-set memory limit
> (change it with the -o command line option)
>
>executing
>
> __SAGE_LAST__:="__SAGE_LAST__";;DoubleCosetRepsAndSizes(\$sage1,\$sage8,\$sage8);;
>
>
> If I recall correctly, the above worked fine a couple of years ago, when
> I achieved the first computation of the mod-2 cohomology of the third
> Conway group.
>
> So, what has changed? Is the memory limit for gap-via-pexpect different
> from the memory limit of "sage -gap"? Has that memory limit changed in
> the past years? How can I work around (i.e., set the memory limit of
> gap-via-pexpect to the apparently sufficient memory limit used by "sage
> -gap")?
>
> Best regards,
> Simon
>
>
--
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 sage-support+unsubscr...@googlegroups.com.
To post to this group, send email to sage-support@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-support] Problem with Sage's pexpect interface to Gap
Hi Simon, set_gap_memory_pool_size() controls the amount of memory GAP and libGAP get if started from Sage. The latter is dynamic, as opposed to "sage --gap" Dima On Sat, Sep 29, 2018 at 7:34 AM Simon King wrote: > > Hi! > > Let G be the third Conway group, S its Sylow 2-subgroup, and > N the normaliser of the centre of S in G. > > Gap is able to compute the list of double coset representatives of N in > G using the command > gap> DC := DoubleCosetRepsAndSizes(G,N,N);; > gap> Length(DC); > 7 > Actually, if I understand correctly, DC is not a list but an iterator, > but for a list of size 7 this shouldn't matter so much. > > Anyway. If I do the above computation in the Sage pexpect interface to > gap, the line > DC = G.DoubleCosetRepsAndSizes(N,N) > gives an error: > RuntimeError: Gap produced error output > Error, reached the pre-set memory limit > (change it with the -o command line option) > >executing > > __SAGE_LAST__:="__SAGE_LAST__";;DoubleCosetRepsAndSizes(\$sage1,\$sage8,\$sage8);; > > > If I recall correctly, the above worked fine a couple of years ago, when > I achieved the first computation of the mod-2 cohomology of the third > Conway group. > > So, what has changed? Is the memory limit for gap-via-pexpect different > from the memory limit of "sage -gap"? Has that memory limit changed in > the past years? How can I work around (i.e., set the memory limit of > gap-via-pexpect to the apparently sufficient memory limit used by "sage > -gap")? > > Best regards, > Simon > > > -- > 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 sage-support+unsubscr...@googlegroups.com. > To post to this group, send email to sage-support@googlegroups.com. > Visit this group at https://groups.google.com/group/sage-support. > For more options, visit https://groups.google.com/d/optout. -- 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 sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at https://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
