#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 nthiery):
Hi!
Replying to [comment:7 rbeezer]:
> I knew you'd have some comments! Thanks for all the helpful advice and
suggestions, on categories, and in general.
:-)
> > 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?
Ok. Or maybe it can be just a helper function for how to list the
elements by default, which would be overridden in Groups.
> > 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?
See #8562, which you are very welcome to review :-) IntegerModRing's
were not yet categorified. I'll upload a patch after running the full
tests on it.
> > 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.
With groupds, there is a possible confusion with the other use of
groupoids (http://en.wikipedia.org/wiki/Groupoid) which is about
having a partially defined operation; but with associativity holding
whenever meaningful.
Thanks to the s, there is no naming clash between Magmas and Magma, so
that's probably fine (http://en.wikipedia.org/wiki/Magma_%28algebra%29)
> Guessing was a "feature" before I found categories. It'll go away.
Great.
> > (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.
Ok; let me know how it goes.
> > - Rename list to index_set, or maybe row_index_set, to avoid
> > confusion with the usual semantic of list.
>
> How about "headings"?
Thinking twice about it, I vote for m.column_keys() / m.row_keys() for
consistency with the d.keys() of a dictionary (which we also use for
Family's, and CombinatorialFreeModule elements).
> > - 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.
Ah, ok, sorry; I thought it would map an element to its position in
the list.
> So maybe there is a better name. "translation"?
names_of_elements? or just names? labels? element_labels?
> > 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.
Another coming soon usage will be character tables.
> > 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,.....
They multiplication table looks very much like a matrix, so one would
want, for u,v elements (not names/labels) of the group to have m[u,v]
be u*v.
> 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.
Yeah, hard point. multiplication / addition is consistent with __mul__
and __add__. So that's probably ok without cluttering the namespace.
By the way: congrats on being essentially the first non Sage-Combinat
contributer to categories :-) How did it go?
Cheers,
Nicolas
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/7555#comment:8>
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.
