#7555: Fix Cayley tables, add operation tables
---------------------------+------------------------------------------------
Reporter: rbeezer | Owner: AlexGhitza
Type: enhancement | Status: needs_review
Priority: minor | Milestone:
Component: algebra | Keywords: cayley table, operation table
Author: | Upstream: N/A
Reviewer: | Merged:
Work_issues: |
---------------------------+------------------------------------------------
Comment(by nthiery):
Hi Rob!
Very nice patch! I'll sure use it soon :-)
Replying to [comment:4 rbeezer]:
> I've tied the new {{{OperationTable}}} class into the categories
framework as a multiplication table for Semigroups and as an addition
table for Commutative Additive Semigroups. I've also added it as a Cayley
table for groups, since I'd like to later expand this somewhat to take
advantage of the extra structure in groups.
That's the way to go!
Out of curiosity: what are the specific features of groups that could
be useful?
> 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"?
> Had a hard time constructing a nontrivial finite additive semigroup, so
the documentation there is barebones right now.
In waiting for something better, you may want to include a test with a
commutative additive group like:
{{{
sage: Z5 = IntegerModRing(5)
}}}
By the way:
{{{
sage: from sage.categories.examples.commutative_additive_monoids
import FreeCommutativeAdditiveMonoid
sage: F=FreeCommutativeAdditiveMonoid(('a', 'b'))
}}}
Is better constructed as::
{{{
sage: F = CommutativeAdditiveMonoids().example(('a','b'))
}}}
And actually should eventually become:
{{{
sage: F = CommutativeAdditiveMonoids().free(('a','b'))
}}}
> As more structures become available in the categories this should be all
ready to go, unchanged. Right now it already makes the multiplication
table available for all groups, rather than just permutation groups.
And for semigroups, which I am very interested in :-) Actually, it
could be generalized to Magmas() (just a binary operation, not
necessarily associative) once we have this category.
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.
(and possibly add an operation_symbol = "+" option?)
- Remove the restriction for the empty operation table, unless
absolutely necessary.
- comparisons by < do not seem that meaningful. I would just test
equality of operation tables. Then, there are two possible
semantics:
- two tables are equal if they correspond to the same algebraic
structure, operation and element order
- two tables are equal if they are equal as "functions", i.e. the
two operations both map the i-th and j-th element to the same
k-th element (that's what the current comparison by list of ints
does)
I don't have a preference yet.
Note: in many other places, we will need a class for matrices with row
and indices indexed by any objects, and not just integers. This is a
good first step, and it will remain to extract a more general super
class. To prepare the ground, I would suggest the following:
- Rename list to index_set, or maybe row_index_set, to avoid
confusion with the usual semantic of list.
- dict is a bit vague. It is related to ranking (see EnumeratedSets).
Maybe row_rank, or row_rank_dict.
Is ascii_table really needed? I would tend to just implement _repr_,
and not teach the user another specific way of getting the
representation.
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.
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.
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.
[1] http://trac.sagemath.org/sage_trac/wiki/CategoriesRoadMap
Cheers,
Nicolas
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/7555#comment:5>
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.
