#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 rbeezer):
Replying to [comment:12 nthiery]:
Hi Nicolas,
> Three minor thing I am hesitating about:
I only see two, not that I'm looking for trouble.
> - 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.
Coercion here could go away - I've perhaps gone overboard with coercion,
envisioning students typing in strings that are not really elements, such
as permutations. So I want to keep coercion in {{{__init__}}}. You are
right, if no coercion in {{{__getitem__}}} then the object does not need
to hold a reference to S.
> - 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.
This struck me as a good idea at first, but again, I'd like a chance to
coerce the contents of {{{elements}}} (when present) into something (S, a
parent), so I'd really like to keep this feature. It's only on creation,
and only once per element. I find coercion is a hard idea for students to
come to grips with, so I'd like to help out as much as possible here and
not assume that the input is pure.
> 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__.
Sure, you can clean-up {{{__getitem__}}} to suit your tastes.
Thanks for all your help with this.
Rob
PS I'm glad I can make Florent's life that much easier. ;-)
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/7555#comment:14>
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.