On Sun, 30 Sep 2018, 10:10 Simon King, <simon.k...@uni-jena.de> wrote:
> Hi Vincent,
>
> On 2018-09-30, Vincent Delecroix <20100.delecr...@gmail.com> wrote:
> > The main problem is that G is a gap group and not a libgap
> > group. By gap group I mean that the interface going through
> > the pexpect interface. The two systems gap and libgap do not
> > seem to share the namespaces (which make sense).
>
> Oops. You are right. After correcting it, my example works just fine.
>
> Sorry for that.
>
> Nonetheless, I have a wishlist concerning libgap:
>
> A) Generator access with dot syntax
>
> I'd like to have that G.1 returns the first generator of the
> group (which it does in GAP language, but neither in the gap pexpect
> interface nor in libgap).
>
> -------
> B) Optional values for libGAP functions
>
> In Gap, it is possible to create functions with
> optional arguments. I have a function in Gap whose definition starts
> like that:
> regularPermutationAction := function(G)
> local gens, N, S, L, gg, forceDefiningGenerators;
> forceDefiningGenerators := ValueOption("forceDefiningGenerators");
>
if you have a nontrivial GAP computation to be done in libgap, why not just
use libgap's function_factory?
Then you don't need to jump various hoops across sage/libgap boundary.
...
>
> In GAP syntax, having a group G, I would call the function as follows:
> P := regularPermutationAction(G: forceDefiningGenerators);;
>
> How would I call it when G is defined in libgap?
> G.regularPermutationAction(forceDefiningGenerators=True)
> doesn't work.
>
> --------
> C) Make it possible to refer to an libgap object in a command string
>
> In gap (the pexpect interface), in the example from B), I'd do
> P = gap('regularPermutationAction({}:
> forceDefiningGenerators)'.format(G.name()))
> and in the example from A), I'd do
> gap('{}.1'.format(G.name()))
> but libgap objects apparently have no name by which they are known in
> the libgap interpreter.
>
> -------
> D) libgap's and gap's methods should have roughly similar semantics
>
> It is really unfortunate that it hasn't been attempted
> to keep libgap as close to the pexpect interface as possible. For
> example:
> 1. sage: libgap('SymmetricGroup(8)')
> "SymmetricGroup(8)"
> sage: type(_)
> <type 'sage.libs.gap.element.GapElement_String'>
> sage: gap.eval('SymmetricGroup(8)')
> 'Sym( [ 1 .. 8 ] )'
> sage: type(_)
> <type 'str'>
> In other words, libgap() behaves roughly like gap.eval()
> 2. sage: libgap.eval('SymmetricGroup(8)')
> Sym( [ 1 .. 8 ] )
> sage: gap('SymmetricGroup(8)')
> SymmetricGroup( [ 1 .. 8 ] )
> In other words, libgap.eval() behaves roughly like 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.
