#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):
Hi Nicolas,
Been working most of the day straightening this up.
Allowing more general operations is a big improvement. See example of
table of commutators of a finite group once I get a patch up. ;-)
> Ok. Or maybe it can be just a helper function for how to list the
> elements by default, which would be overridden in Groups.
I'll include a note in the source to this effect.
> 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.
Aah - that answers lots of questions. Thanks. "categorified"?? Your
English is excellent, but that is pretty bad. ;-) ;-) ;-) (But it was I
might have said too).
> > > 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)
Got it.
> > 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.
Not too bad. Empty latex table is nice, empty ascii table is so-so, but
not worth anymore effort.
> > > - 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).
I did index_set. ;-(
> > > - 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?
Used translation. :-(
> 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.
OK, that should be easy.
> 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?
Nice. I like it. I'm a fan. And your ring patch will help me recognize
when/how categorification happens.
I'm running out of time on this, it's semester break this week, so I'll
throw something up soon.
Rob
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/7555#comment:9>
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.
