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()
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
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 previ
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:
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.
>
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
>
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,
> ga
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
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 th
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
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: li
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
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
13 matches
Mail list logo
