#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!
Replying to [comment:11 rbeezer]:
> Patch is complete enough to review.
> But I'd like this to move forward independently, since my time will be
limited for a few weeks.
Thanks for you work on this. This sounds very good, so will set up a
positive review as soon as I get a running 4.3.4 sage to launch the
tests.
Three minor thing I am hesitating about:
- Do we really want coercion in __getitem__. By default, I would tend
to not do it for efficiency, unless a strong use case comes up in
practice.
- In OperationTable, there is now a bit of redundancy between S and
elements; the only place where S is used is to coerce the elements.
In particular, what about just accepting:
OperationTable(iterable, operation)
where iterable is any iterable (up to the user to make sure that it
is finite).
No big deal; this can be added later if desirable.
I'll probably post a small reviewer patch with once I can double check
the html doc with micro typos and, if you agree, removing coercion in
__getitem__.
Cheers,
Nicolas
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/7555#comment:12>
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.
