#10963: More functorial constructions
-------------------------------------+-------------------------------------
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_work
Priority: major | Milestone:
Component: categories | Resolution:
Keywords: | Merged in:
Authors: Nicolas M. Thiéry | Reviewers: Simon King
Report Upstream: N/A | Work issues: Reduce startup time
Branch: | by 5%. Avoid "recursion depth
Dependencies: #11224, #8327, | exceeded (ignored)".
#10193, #12895, #14516, #14722, | Commit:
#13589 | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by SimonKing):
In some posts (don't find them right now), I said that adding axioms is
easier than forming a join category, and thus one should try to find an
implementation that does not rely on plain joins. Let me try to elaborate
on it.
It seems to me that there are (in Sage) two types of categories. My
suggestion boils down to: "Implement two different Python classes for
these two types of categories".
Firstly, there are categories that stipulate the existence of certain
algebraic operations. Most notably: `AdditiveMagmas()` (providing the
operator "+") and `Magmas()` (providing the operator "*"), but conceivably
there should also be something like `RightGSets(G)` (providing the
operator "`^`" or perhaps another version of "*") and `LeftGSets(G)`.
Probably one can formulate all of them as the categories of sets with
actions by some '''free''' operad. Lets call them "free operator
categories".
And secondly, there are "axiom categories" that stipulate certain axioms
that hold for the operators defined in one of the "free operator
categories". For example,
{{{
AdditiveCommutative() = AdditiveMagmas().Commutative()
}}}
is a category which is a sub-category of `AdditiveMagmas()` in which the
"+"-operator is commutative; and the law of (left/right/twosided)
distributivity is encoded as a sub-category of the join of
`AdditiveMagmas()` and `Magmas()`.
Hence, an "axiom category" should tell what operations it is referring to,
and this can be expressed by a (join of) "free operator categories".
Hence, `Rings().free_operator_category()` would return
`Category.join([AdditiveMagmas(), Magmas()])`.
And I guess the join of such "free operator categories" is trivial: We
have one non-join free operator category for each algebraic operation (*,
+, /, ...), and forming the join of two free operator categories just
amounts to remove duplicates.
What about the join of two "axiom categories"? Well, first of all, we need
to form the join of the underlying free operator categories (which is
trivial), and then combine the two lists of axioms. Here is where one can
implement theorems such as "a finite commutative division ring is a
field". But again, the default is to remove duplicate axioms.
Possible approach to an implementation:
- I guess `class FreeOperatorCategory` should provide exactly one
operation (multiple operations will be implemented by joins). It should
have a method `C.operator()` returning `operator.mul` or `operator.add` or
`operator.sub` and so on, telling what Python operator it corresponds to.
And it should request certain abstract methods by which the operation is
implemented (i.e., `_add_` or `_mul_`).
- `class CategoryWithAxioms` keeps
1. a non-empty duplicate-free list FOC of non-join "free operator
categories", and
2. a duplicate-free list EAC of "elementary (non-join) axiom
categories". In a non-join axiom category, this second list is empty.
In addition, it has to provide some `_test_...` method(s) for parent
and/or element classes, testing against the axioms.
Hence, `C=Rings()` would have `C.FOC = [AdditiveMagmas(),
SubtractiveMagmas(), Magmas()]` and `C.EAC = [Distributive(),
AdditiveCommutative(), AdditiveAssociative(), AdditiveInverses(),
Associative()]` (perhaps I forgot some axioms).
Now, about `C.super_categegories()`.
- If `C` is a non-join free operator category, then it returns
`[Objects()]`, which is the only operator-free category (note that
`Sets()` is a free operator category for the operator "in", requesting an
abstract parent method `__contains__`).
- If `C` is a join of non-join free operator categories, then it returns
the list of these non-join free operator categories.
- If `C` is an axiom category, then it returns the list `C.FOC+C.EAC`
after removing those items of `C.FOC` which are already covered by one of
the elementary axiom categories from `C.EAC`.
__Example__
Enumerated rings `ER` are a join of rings (with FOC and EAC as above) and
enumerated sets. The latter is a free operator category with empty
operator but requested abstract parent method `__iter__`. Hence, I would
suggest to have
{{{
ER.super_categories() == [EnumeratedSets(), Distributive(),
AdditiveCommutative(), AdditiveAssociative(), AdditiveInverses(),
Associative()]
}}}
This is because `EnumeratedSets()` is the only FOC that is not subject to
one of the EAC. Further,
{{{
AdditiveInverses().super_categories() == [AdditiveMagmas(),
SubtractiveMagmas()]
}}}
i.e., the super categories just state that the axioms are formulated in
terms of + and -.
Hm. We also have "0" (zero). Should one say that "0" is a null-ary
operator, and thus "0" is defined in a free operator category, and that
the axiomatic properties of "0" as additive unit is then defined in an
elementary axiom category `WithAdditiveUnit()`?
Anyway. This is the approach that I would have taken. Do you find anything
useful in this approach?
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:84>
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.
