#7555: Fix Cayley tables, add operation tables
---------------------------+------------------------------------------------
Reporter: rbeezer | Owner: AlexGhitza
Type: enhancement | Status: needs_work
Priority: minor | Milestone:
Component: algebra | Keywords: cayley table, operation table
Author: | Upstream: N/A
Reviewer: | Merged:
Work_issues: |
---------------------------+------------------------------------------------
Comment(by rbeezer):
Replying to [comment:5 nthiery]:
Dear Nicolas,
I knew you'd have some comments! Thanks for all the helpful advice and
suggestions, on categories, and in general.
> That's the way to go!
Yes, it certainly is. ;-)
> Out of curiosity: what are the specific features of groups that could
> be useful?
Grab a normal subgroup, as close to size sqrt(n) as you can get (perhaps
automatically), then order elements in bunches as cosets. You can
sometimes see the quotient structure in the table, especially if done
graphically. But maybe this belongs higher up the hierarchy?
> > The old Cayley table was used to build Latin squares. I believe the
behavior now with the new cayley table will be identical - IF the identity
is the first element of the group.
>
> Isn't that more "if the elements are listed in the same order"?
That would of course be sufficient. The code is a bit cryptic, but it
appeared to me that if the identity was first, then the elements were
numbered in the order they were listed. But I didn't study it that
carefully, since I was going to pull it out anyway. Hopefully the change
doesn't cause anybody any trouble.
> In waiting for something better, you may want to include a test with a
> commutative additive group like:
>
> {{{
> sage: Z5 = IntegerModRing(5)
> }}}
I tried this repeatedly. You get {{{addition_table}}} with tab
completion, but then
{{{
AttributeError: 'IntegerModRing_generic' object has no attribute
'addition_table'
}}}
when you try to execute it. Similarly for {{{cayley_graph}}}. And
{{{FiniteField}}}s I just assumed rings were not plugged-in yet. Is there
an easy fix?
> Is better constructed as::
>
> {{{
> sage: F = CommutativeAdditiveMonoids().example(('a','b'))
> }}}
Will do.
> Actually, it
> could be generalized to Magmas() (just a binary operation, not
> necessarily associative) once we have this category.
Yes, I wanted this category. Will there be two - additive and
multiplicative? Also called "groupoids" if we want avoid confusion with
the CAS. Doing {{{search_src}}} on "magma" turns up lots of things
related to the program, not the structure.
> I browsed quickly through the patch. Here are some suggestions for
> improvements:
>
> - Pass the operation as a function (like operator.mul)
> Then OperationTable will be useful for any binary operation
>
> - For addition or multiplication, the user won't call directly
> OperationTable, but rather use S.addition_table() /
> S.multiplication_table(). So I would remove the guessing
> feature, and make ``operation`` a required parameter.
Guessing was a "feature" before I found categories. It'll go away.
> (and possibly add an operation_symbol = "+" option?)
>
> - Remove the restriction for the empty operation table, unless
> absolutely necessary.
Didn't check, but thought I'd have to add lots more logic to handle this
case. Maybe not.
> - Rename list to index_set, or maybe row_index_set, to avoid
> confusion with the usual semantic of list.
How about "headings"?
> - dict is a bit vague. It is related to ranking (see EnumeratedSets).
> Maybe row_rank, or row_rank_dict.
The returned dictionary pairs elements with their names. Names can be any
string, not just integers, so this doesn't feel like a ranking or an
enumerated set to me. It's more of a translation table. So maybe there
is a better name. "translation"? But I think rank would be confusing.
> Is ascii_table really needed? I would tend to just implement _repr_,
> and not teach the user another specific way of getting the
> representation.
OK
> By the way: several other Sage objects (like matrices, partitions,
> ...) are starting to have a 2d ascii art representation. We should
> standardize the handling of those.
Yes, I did much the same thing once already for Sudoku puzzles.
> Please add (and use?) a __getitem__ method. It will make
> OperationTable not only useful for printing, but also as a useful data
> structure for computations.
Not sure how you mean this to work? If T is a table, then T[i]=<element>,
or T[i,j]=<table-entry>?? More precisely,.....
> The last issue is the name of the methods. When we discussed this at
> Sage Days 15, we had settled for P.product(x,y) and P.summation(x,y)
> as names for the two operations (the choice was not that clear, and
> the prevailing argument has been consistency with prod and sum
> respectively, and naming the *result* of the operation on x and y)
> [1]. Consistency would then call for P.product_table and
> P.summation_table, though that is not so nice.
I really had students in mind as I built this, though everybody might find
it useful. "product" is OK, "summation" sounds like more than two terms.
In any event, what about having both (ie product and multiplication,
summation and addition)? I know people don't like this, and it clutters
up tab-completion. Permutation groups had {{{multiplication_table}}} as
an alias for {{{cayley_table}}}. I'd really like this to be dead-obvious
for the beginner finding their way in Sage.
Thanks again for the interest and help!
Rob
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/7555#comment:7>
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.
