#17160: Finitely generated axiom for (mutiplicative) magmas, semigroups,
monoids,
groups
-------------------------------------+-------------------------------------
Reporter: nthiery | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: sage-6.4
Component: categories | Resolution:
Keywords: | Merged in:
Authors: Nicolas M. Thiéry | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/nthiery/categories/finitely- | f027ce2b5e1abe22d49bcdc96f2cfeebced8fc16
generated-magmas-17160 | Stopgaps:
Dependencies: |
-------------------------------------+-------------------------------------
Comment (by nthiery):
Replying to [comment:6 tscrim]:
> I know this isn't set for review yet,
Thanks for having looked at it!
> but just to note that a finite magma is automatically finitely
generated. So I think we should have this reflected in the category
structure; in particular, so we don't have lines like this:
> {{{
> Parent.__init__(self, category =
Semigroups().Finite().FinitelyGenerated())
> }}}
As stated in the description, the point of the ticket is precisely to
make a distinction between finite magmas (which are indeed finitely
generated by definition), and finite monoids that are explicitly
endowed with a finite set of generators. The new axiom is about the
latter. So, above, we anyway want something like:
Semigroups().Finite().XXX()
Granted, the current name of the axiom is misleading, and I am
hesitant about it. I also considered:
sage: Groups().Finite().WithFiniteSetOfGenerators()
Category of groups with finite set of generators
It's very explicit but feels like heavy notation; and it does not feel
as appealing as "finitely generated" which immediately rings a bell in
a mathematician's head. Also, it seems to me that being "finitely
generated" is rather useless computationally speaking if no finite set
of generators is provided; so we would not be using that nice name for
a weaker purpose anyway.
I guess that's the main design decision to be taken in this
ticket. The rest is rather straightforward.
Ah, yes, the other design decision is whether it's acceptable to break
backward compatibility. I'll be the first one to be hurt by this
change, and I believe it's worth it ...
Opinions anyone?
> If you need someone to review it, just let me know when this is ready.
Ok, thanks! Darij would be a good candidate to give feedback too!
Cheers,
Nicolas
--
Ticket URL: <http://trac.sagemath.org/ticket/17160#comment:7>
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 unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
