#10963: More functorial constructions
-------------------------+-------------------------------------------------
Reporter: | Owner: stumpc5
nthiery | Status: needs_work
Type: | Milestone:
enhancement | Resolution:
Priority: major | Merged in:
Component: | Reviewers: Simon King
categories | Work issues: Reduce startup time by 5%. Avoid
Keywords: | "recursion depth exceeded (ignored)". Trivial
Authors: | doctest fixes.
Nicolas M. Thiéry | Dependencies: #11224, #8327, #10193, #12895,
Report Upstream: N/A | #14516, #14722, #13589
Branch: |
Stopgaps: |
-------------------------+-------------------------------------------------
Comment (by SimonKing):
Replying to [comment:56 nthiery]:
> Replying to [comment:54 SimonKing]:
> > That's the point: In my approach, this category would be constructed
on the fly, by means of a dynamic construction.
>
> We do not even want to construct it on the fly! FiniteFields satisfies
> at least four axioms that can apply to Magmas (Associative, Finite,
> Unital, Commutative). We do not want the category hierarchy above
> FiniteFields to contain {2^4} categories (most of which being trivial)
just for Magmas.
OK, that's a considerable change. In the "good" old times, a category C
was (by definition) a sub-category of another category D, if and only if D
was contained in `C.all_super_categories()`. So, you say this shall change
(or already has?).
> Which is exactly what I want since finite commutative rings is
> trivial, and realized as a join category. There is no point in adding
> join categories in all_super_categories.
OK, it somehow convinces me that we don't want to create categories "on
the fly" that do not provide any additional information (methods etc)
beyond the categories that were created anyway.
But then, I still don't see why this should be implemented by a plain join
category.
Do we agree that there is a category `Magmas().Commutative()`, such that
all information on `Algebras(ZZ).Commutative()` is provided by
`Algebras(ZZ)` together with `Magmas().Commutative()`? Sure, we could then
implement `Algebras(ZZ).Commutative()` by a `JoinCategory`.
But then, I would expect that we can have a class which is similar to
`JoinCategory` but is specially designed and thus faster. After all,
creating the join of a list of categories should be more complicated then
adding a list of "axiom categories" (such as `Magmas().Commutative()` and
`Magmas().Division()` and `Sets().Finite()`) to a given category (such as
`Rings()`).
Anyway, I think my original suggestion of creating classes for categories-
with-axiom on the fly was probably not so good. But I think I will try to
experiment with the other idea (using a specially designed "mock join" for
adding axioms).
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:57>
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/groups/opt_out.
