#13102: PermutationGroup.all_blocks from GAP
---------------------------------+------------------------------------------
Reporter: ncohen | Owner: joyner
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-5.3
Component: group theory | Resolution:
Keywords: | Work issues:
Report Upstream: N/A | Reviewers:
Authors: Nathann Cohen | Merged in:
Dependencies: | Stopgaps:
---------------------------------+------------------------------------------
Comment (by jasonbhill):
I like this, but I'd like to bring up some issues and propose solutions.
I'll help with writing, as much of this will depend on code I've written
to the relevant file.
'''Issues:'''
1. We should implement more than just "!AllBlocks" from GAP. First, this
creates a naming problem for tab completion in sage. I propose the names
such as "blocks," "blocks_maximal," "blocks_all_representatives," and so
on.
1. GAP and Sage view permutation group domains differently. With certain
automatically generated structures, this won't be an issue. But, with a
group like <(2,3)>, which is viewed as transitive in GAP and intransitive
in Sage (it fixes 1), we have an issue. I'm going to write the
"non_fixed_points()" command that currently exists as an alias to
"support()" and redefine the transitivity, regularity, etc. commands with
this instead. (That will be backwards compatible. It's just that
"support()" is more consistent with literature than "non_fixed_points()"
and we should be using that if we're talking about blocks.) That's really
a trivial change, but I should have realized this when I wrote
"non_fixed_points()" in the first place. My bad. It will still exist and
function in any case.
1. What isn't trivial is how these functions should apply to various
groups. I've seen on the GAP lists some questions about GAP's block
functions. The literature does largely discuss blocks for only transitive
groups, but the definition of a block doesn't require it. As my research
area is intransitive groups, this annoys me and GAP's functions are pretty
inadequate. I think it should be relatively obvious that a maximal non-
trivial block system for an intransitive group should simply consist of
the orbits. A generic block system for an intransitive group should return
a non-trivial block system on orbits, including the consideration of fixed
points sitting outside of a transitive component (as happens in Sage and
does not in GAP). I'll work on this and come up with something that makes
sense.
1. As in GAP, we should have optional domain and seed parameters. This
should function seamlessly with issue (3). I'll work on that.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/13102#comment:3>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
