[Sage] #10963: More functorial constructions
Sage
---------------------------------+------------------------------------------
Reporter: nthiery | Owner: nthiery
Type: enhancement | Status: new
Priority: major | Milestone:
Component: categories | Keywords:
Author: Nicolas M. Thiéry | Upstream: N/A
Reviewer: | Merged:
Work_issues: |
---------------------------------+------------------------------------------
The patch under development on the Sage-Combinat queue implements:
- The algebra of a finite enumerated set is a finite dimensional algebra
- Commutative additive semigroup and monoid algebras
- More documentation for IsomorphicObjects and other doc improvements
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica, and MATLAB
Sage
---------------------------+------------------------------------------------
Type: enhancement | Status: new
Priority: major | Milestone:
Component: categories | Keywords:
Reviewer: | Author: Nicolas M. Thiéry
Merged: | Dependencies: #11224
---------------------------+------------------------------------------------
Changes (by nthiery):
* dependencies: => #11224
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:1>
Sage
---------------------------+------------------------------------------------
Type: enhancement | Status: new
Priority: major | Milestone:
Component: categories | Keywords:
Reviewer: | Author: Nicolas M. Thiéry
Merged: | Dependencies: #11224
---------------------------+------------------------------------------------
Old description:
> The patch under development on the Sage-Combinat queue implements:
>
> - The algebra of a finite enumerated set is a finite dimensional algebra
> - Commutative additive semigroup and monoid algebras
> - More documentation for IsomorphicObjects and other doc improvements
The patch under finalization on the Sage-Combinat queue implements:
- Support for full subcategories defined by a predicate on the objects
(Finite, Infinite, FiniteDimensional, Commutative, Graded, Facade),
and joins thereof:
{{{
sage: Category.join([Groups(), Sets().Finite()])
Category of finite groups
sage: Category.join([Algebras(QQ).Finite(), Monoids().Commutative()])
Join of Category of commutative algebras over Rational Field and
Category of finite monoids
}}}
- More mathematical rules:
- A subquotient of a finite set is a finite set
- The algebra of a finite set is finite dimensional
- The algebra of a commutative magma is commutative
- Algebras of commutative additive semigroups and monoids
--
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:2>
Sage
---------------------------+------------------------------------------------
Priority: major | Milestone:
Component: categories | Keywords:
Reviewer: | Author: Nicolas M. Thiéry
Merged: | Dependencies: #11224
---------------------------+------------------------------------------------
* owner: nthiery => stumpc5
Comment:
Hi Nicolas,
How far is this patch -- I just saw that the UCF patch depends on this.
I didn't actually figure out how it depends, I just get a trivial rebase,
and then an import loop which wasn't easily fixable. The problem was my
use of CombinatorialFreeModule...
Thx, Christian
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:3>
Sage
---------------------------+------------------------------------------------
Reporter: nthiery | Owner: stumpc5
Priority: major | Milestone:
Component: categories | Keywords:
Reviewer: | Author: Nicolas M. Thiéry
---------------------------+------------------------------------------------
Changes (by stumpc5):
* dependencies: #11224 => #11224, #8327
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:4>
Sage
---------------------------+------------------------------------------------
Reporter: nthiery | Owner: stumpc5
Priority: major | Milestone:
Component: categories | Keywords:
Reviewer: | Author: Nicolas M. Thiéry
Merged: | Dependencies: #11224, #8327
---------------------------+------------------------------------------------
* cc: SimonKing (added)
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:5>
Sage
---------------------------------+------------------------------------------
Type: enhancement | Status: needs_info
Component: categories | Keywords:
Merged: | Dependencies: #11224, #8327
Changes (by SimonKing):
* status: new => needs_info
* work_issues: => Find dependencies
Comment:
It turns out that many hunks of that patch fail to apply, when one starts
with sage-4.8.alpha0 plus the new cython spkg from #11761 plus the rebased
patch from #8327. So, there are further dependencies from the combinat
queue. Could you try to find out which they are, and post them here?
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:6>
Sage
-------------------------------------------------------------------+--------
Type: enhancement | Status: needs_info
Component: categories | Keywords:
Merged: | Dependencies: #11224, #8327
Changes (by SimonKing):
* work_issues: Find dependencies => Find dependencies. Finite
dimensional vector spaces
Comment:
Working with the combinat queue, I could do some first tests. What I find
very strange is the fact that the category of vector spaces coincides with
the category of finite-dimensional vector spaces:
{{{
sage: VectorSpaces(QQ).FiniteDimensional() is VectorSpaces(QQ)
True
}}}
Is that really intended? I thought that the idea of this ticket is to
create new categories dynamically. Hence, even though there previously was
no specific implementation of the category of finite dimensional vector
spaces, the construction `VectorSpaces(QQ).FiniteDimensional()` would
automatically create one. Or am I misunderstanding something?
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:7>
Sage
-------------------------------------+--------------------------------------
Type: enhancement | Status: needs_info
Component: categories | Resolution:
Keywords: | Work issues: Find dependencies. Finite dimensional vector spaces
Report Upstream: N/A | Reviewers:
Authors: Nicolas M. Thiéry | Merged in:
Dependencies: #11224, #8327 | Stopgaps:
-------------------------------------+--------------------------------------
Changes (by saliola):
* cc: saliola (added)
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:8>
Sage
-------------------------------------+--------------------------------------
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_info
Keywords: | Work issues: Find dependencies. Finite dimensional vector spaces
Report Upstream: N/A | Reviewers:
Authors: Nicolas M. Thiéry | Merged in:
Dependencies: #11224, #8327 | Stopgaps:
-------------------------------------+--------------------------------------
* cc: aschilling (added)
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:9>
Sage
-------------------------------------+--------------------------------------
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_info
Keywords: | Work issues: Find dependencies. Finite dimensional vector spaces
Report Upstream: N/A | Reviewers:
Authors: Nicolas M. Thiéry | Merged in:
Dependencies: #11224, #8327 | Stopgaps:
-------------------------------------+--------------------------------------
Comment (by dimpase):
Would you mind actually uploading the patch in question here?
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:10>
Sage
-------------------------------------+--------------------------------------
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_info
Keywords: | Work issues: Find dependencies. Finite dimensional vector spaces
Report Upstream: N/A | Reviewers:
Authors: Nicolas M. Thiéry | Merged in:
Dependencies: #11224, #8327 | Stopgaps:
-------------------------------------+--------------------------------------
Old description:
>
> - Support for full subcategories defined by a predicate on the objects
> (Finite, Infinite, FiniteDimensional, Commutative, Graded, Facade),
> and joins thereof:
>
> {{{
> sage: Category.join([Groups(), Sets().Finite()])
> Category of finite groups
> sage: Category.join([Algebras(QQ).Finite(), Monoids().Commutative()])
> Join of Category of commutative algebras over Rational Field and
> Category of finite monoids
> }}}
>
> - More mathematical rules:
> - A subquotient of a finite set is a finite set
> - The algebra of a finite set is finite dimensional
> - The algebra of a commutative magma is commutative
> - Algebras of commutative additive semigroups and monoids
The patch under finalization on the Sage-Combinat queue implements:
- Support for full subcategories defined by a predicate on the objects
(Finite, Infinite, FiniteDimensional, Commutative, Graded, Facade),
and joins thereof:
{{{
sage: Category.join([Groups(), Sets().Finite()])
Category of finite groups
sage: Category.join([Algebras(QQ).Finite(), Monoids().Commutative()])
Join of Category of commutative algebras over Rational Field and
Category of finite monoids
}}}
- More mathematical rules:
- A subquotient of a finite set is a finite set
- The algebra of a finite set is finite dimensional
- The algebra of a commutative magma is commutative
- Algebras of commutative additive semigroups and monoids
-more_functorial_constructions-nt.patch and follow ups.
--
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:11>
Sage
-------------------------------------+--------------------------------------
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_info
Keywords: | Work issues: Find dependencies. Finite dimensional vector spaces
Report Upstream: N/A | Reviewers:
Authors: Nicolas M. Thiéry | Merged in:
Dependencies: #11224, #8327 | Stopgaps:
-------------------------------------+--------------------------------------
Comment (by nthiery):
Little update: after two good weeks of work, here is the status of the
patch in the Sage-Combinat queue:
- 100% doctested
- Passes all long tests (with the patches above it; well, there is a
failure in sage_object.pyx, but it is caused by an above tests)
- Reasonably documented, but needs a pass of proof reading and an overview
documentation
- Has not yet been tested for performance; but creating an instance of
each of the categories in sage.categories (120 of them) takes less than
0.1s, so nothing horrible a priori.
- Needs some discussions for good naming conventions and later directions.
I have made a precise list which I'll post later on.
- Has some trivial dependencies on unrelated patches that are close to
positive review; I need to figure out the exact list.
In short: getting ready for review next week!
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:12>
Sage
----------------------------------------------------------------+-----------
Type: enhancement | Status: needs_info
Keywords: | Work issues: Find dependencies. Finite dimensional vector spaces
Report Upstream: N/A | Reviewers:
Authors: Nicolas M. Thiéry | Merged in:
----------------------------------------------------------------+-----------
Changes (by nthiery):
* dependencies: #11224, #8327 => #11224, #8327, #10193 #12895, #14516,
#14722
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:13>
Sage
-------------------------------------------------------------------------+--
Type: enhancement | Status: needs_info
Component: categories | Resolution:
Keywords: | Work issues:
Authors: Nicolas M. Thiéry | Merged in:
-------------------------------------------------------------------------+--
Changes (by nthiery):
* dependencies: #11224, #8327, #10193 #12895, #14516, #14722 => #11224,
#8327, #10193, #12895, #14516,
#14722, #13589
* work_issues: Find dependencies. Finite dimensional vector spaces =>
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:14>
Sage
-------------------------------------------------------------------------+--
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_info
Keywords: | Work issues:
Report Upstream: N/A | Reviewers:
Authors: Nicolas M. Thiéry | Merged in:
Dependencies: #11224, #8327, #10193, #12895, #14516, #14722, #13589 | Stopgaps:
-------------------------------------------------------------------------+--
Comment (by SimonKing):
Just for the record: I currently have applied
{{{
trac_12876_category_abstract_classes_for_hom.patch
trac11935_weak_pickling_by_construction-nt.patch
trac_11935-weak_pickling_by_construction-review-ts.patch
trac_12895-subcategory-methods-nt.patch
trac_12895-review.patch
trac_10193-graded_sets-rebased.patch
trac_10193-graded_sets-review-ts.patch
trac_13589-categories-c3_under_control-nt.patch
trac13589_cmp_key_attribute.patch
trac13589_improve_startuptime.patch
trac_12630_quivers_v2.patch
trac12630_refactor_code.2.patch
trac_14722-lazy_import_at_startup-nt.patch
trac_14266_ascii_art_13_05_15_EliX-jbp.patch
trac_14266-ascii_art-review-ts.patch
trac_14266_terminal_width.patch
trac_14402-tensor_product_infinite_crystals-ts.patch
trac_14143-alcove-path-al.3.patch
trac_14413-elementary_crystals-bs.patch
trac_14516-crystals_speedup-ts.patch
}}}
on top of sage-5.10.rc1 (I think these are all dependencies).
So, as soon as Nicolas told me how to get the patch from git and what is
meant by "and follow-ups", I can start reviewing!
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:15>
Sage
-------------------------------------------------------------------------+--
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_info
Keywords: | Work issues:
Report Upstream: N/A | Reviewers:
Authors: Nicolas M. Thiéry | Merged in:
Dependencies: #11224, #8327, #10193, #12895, #14516, #14722, #13589 | Stopgaps:
-------------------------------------------------------------------------+--
Comment (by SimonKing):
With these list I gave above, the patch does not apply. Some of it might
be to blame the latest version of my
`trac13589_improve_startuptime.patch`. So, let's try to remove this. But
there seem to be further dependencies.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:16>
Sage
-------------------------------------------------------------------------+--
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_info
Keywords: | Work issues:
Report Upstream: N/A | Reviewers:
Authors: Nicolas M. Thiéry | Merged in:
Dependencies: #11224, #8327, #10193, #12895, #14516, #14722, #13589 | Stopgaps:
-------------------------------------------------------------------------+--
Comment (by SimonKing):
Even when I remove `trac13589_improve_startuptime.patch`, I still get 4
mismatches and 1 noise in category.py, 4 mismatches in
category_singleton.pyx, and 1 mismatch and 2 noises in c3_controlled.pyx
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:17>
Sage
-------------------------------------------------------------------------+--
Reporter: nthiery | Owner: stumpc5
Priority: major | Milestone:
Keywords: | Work issues:
Dependencies: #11224, #8327, #10193, #12895, #14516, #14722, #13589 | Stopgaps:
-------------------------------------------------------------------------+--
* status: needs_info => needs_review
* reviewer: => Simon King
Comment:
Back at work. These patches on top of sage-5.11.b3 do apply:
{{{
trac_14516-crystals_speedup-ts.2.patch
trac_14722-lazy_import_at_startup-nt.patch
trac_13589-categories-c3_under_control-nt.patch
trac_10963-more_functorial_constructions-nt.patch
}}}
(the last patch applies with a little fuzz)
However, if we decide to include the two additional patches from #13589,
then the last patch needs to be rebased.
For now, I'll try without the two additional patches, since they only
concern performance (and seem to have disappointingly little effect).
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:18>
Sage
-------------------------------------------------------------------------+--
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_review
Keywords: | Work issues:
Report Upstream: N/A | Reviewers: Simon King
Authors: Nicolas M. Thiéry | Merged in:
Dependencies: #11224, #8327, #10193, #12895, #14516, #14722, #13589 | Stopgaps:
-------------------------------------------------------------------------+--
Comment (by nthiery):
Hi Simon!
Great that the patches apply.
I am happy to handle the rebase on top of the extra patches for #13589. I
also have some modifications in primer.py that I need to finish merging
it. I'll try to finish this today. I guess there is enough to review
elsewhere to keep you busy until then :-)
Thanks a lot!
Cheers,
Nicolas
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:19>
Sage
-------------------------------------------------------------------------+--
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_review
Component: categories | Resolution:
Keywords: | Work issues: Rebase wrt. #13589
Authors: Nicolas M. Thiéry | Merged in:
Dependencies: #11224, #8327, #10193, #12895, #14516, #14722, #13589 | Stopgaps:
-------------------------------------------------------------------------+--
* work_issues: => Rebase wrt. #13589
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:20>
Sage
-------------------------------------------------------------------------+--
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_review
Keywords: | Work issues: Rebase wrt. #13589
Report Upstream: N/A | Reviewers: Simon King
Authors: Nicolas M. Thiéry | Merged in:
Dependencies: #11224, #8327, #10193, #12895, #14516, #14722, #13589 | Stopgaps:
-------------------------------------------------------------------------+--
Comment (by SimonKing):
Just to make sure I understand correctly: During `__init__` of a group
algebra, only the coercion from the group is registered, since the
coercion from the base ring is registered during `__init_extra__`, which
is obtained from the category?
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:21>
Sage
-------------------------------------------------------------------------+--
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_review
Keywords: | Work issues: Rebase wrt. #13589
Report Upstream: N/A | Reviewers: Simon King
Authors: Nicolas M. Thiéry | Merged in:
Dependencies: #11224, #8327, #10193, #12895, #14516, #14722, #13589 | Stopgaps:
-------------------------------------------------------------------------+--
Comment (by nthiery):
Replying to [comment:21 SimonKing]:
> Just to make sure I understand correctly: During `__init__` of a group
algebra, only the coercion from the group is registered, since the
coercion from the base ring is registered during `__init_extra__`, which
is obtained from the category?
Yes indeed!
There is nothing specific to do for GroupAlgebras about this feature,
since it's already provided by Algebras.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:22>
Sage
-------------------------------------------------------------------------+--
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_review
Keywords: | Work issues: Rebase wrt. #13589
Report Upstream: N/A | Reviewers: Simon King
Authors: Nicolas M. Thiéry | Merged in:
Dependencies: #11224, #8327, #10193, #12895, #14516, #14722, #13589 | Stopgaps:
-------------------------------------------------------------------------+--
Comment (by SimonKing):
There is now a category of non-associative algebras. But that's
misleading, because it certainly contains all associative algebras too,
isn't it? I'd say that "non-associative non-unital (non-commutative) (non-
finite-dimensional) algebras" should simply be "algebras".
In other words, I am against mentioning the ''absence'' of an axiom in the
category name. Only the ''presence'' of an axiom must play a role.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:23>
Sage
-------------------------------------------------------------------------+--
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_review
Keywords: | Work issues: Rebase wrt. #13589
Report Upstream: N/A | Reviewers: Simon King
Authors: Nicolas M. Thiéry | Merged in:
Dependencies: #11224, #8327, #10193, #12895, #14516, #14722, #13589 | Stopgaps:
-------------------------------------------------------------------------+--
Comment (by nthiery):
Replying to [comment:23 SimonKing]:
> There is now a category of non-associative algebras. But that's
misleading, because it certainly contains all associative algebras too,
isn't it? I'd say that "non-associative non-unital (non-commutative) (non-
finite-dimensional) algebras" should simply be "algebras".
>
> In other words, I am against mentioning the ''absence'' of an axiom in
the category name. Only the ''presence'' of an axiom must play a role.
Yeah, that's been a recurrent issue. I agree that this is not nice,
even though it's relatively common practice in maths to label as
"non-foo things" the larger field of study where one is interested in
things that are "not necessarily foo". For non associative non unital
algebras, Florent mentionned yesterday that "magmatic algebras" was
fairly standard, and I am happy to go with it. Do you have a better
name for "non unital algebras"? I am not really keen on
"NotNecessarilyUnitalAlgebras".
Cheers,
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:24>
Sage
-------------------------------------------------------------------------+--
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_review
Keywords: | Work issues: Rebase wrt. #13589
Report Upstream: N/A | Reviewers: Simon King
Authors: Nicolas M. Thiéry | Merged in:
Dependencies: #11224, #8327, #10193, #12895, #14516, #14722, #13589 | Stopgaps:
-------------------------------------------------------------------------+--
Comment (by SimonKing):
Replying to [comment:24 nthiery]:
> Do you have a better
> name for "non unital algebras"? I am not really keen on
> "NotNecessarilyUnitalAlgebras".
Yes. A not necessarily unital not necessarily associative not necessarily
finite-dimensional not necessarily noetherian not necessarily ... is
commonly known as an '''algebra'''.
In other words, I suggest to name the categories exactly parallel to the
axioms it provides. Actually, before reading your patch, I thought that
you aim to ''automatically'' create a category of "associative algebras",
given the category of algebras and the axiom "associative".
Hence, I think it should be
{{{
algebras
/ \
associative algebras unital algebras
\ /
associative unital algebras
}}}
and similar for commutative algebras, commutative associative algebras,
commutative associative unital algebras, and so on.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:25>
Sage
-------------------------------------------------------------------------+--
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_review
Priority: major | Milestone:
Component: categories | Resolution:
Keywords: | Work issues: Rebase wrt. #13589
Report Upstream: N/A | Reviewers: Simon King
Authors: Nicolas M. Thiéry | Merged in:
Dependencies: #11224, #8327, #10193, #12895, #14516, #14722, #13589 | Stopgaps:
-------------------------------------------------------------------------+--
Comment (by nthiery):
Replying to [comment:25 SimonKing]:
> Yes. A not necessarily unital not necessarily associative not
> necessarily finite-dimensional not necessarily noetherian not
> necessarily ... is commonly known as an '''algebra'''.
Yup, and that's indeed what Wikipedia says which is a good
point. However in many textbooks and other pieces of literature
"algebra" implicitly includes "associative" and "unital" (for the same
reason that it will be heavy for us to write almost everywhere
Algebras().Associative().Unital()).
More importantly: changing the semantic current "Algebras" in Sage
would be seriously backward incompatible. And we would have to think
about what we want to do about categories like "HopfAlgebras" to keep
things consistent.
So I definitely see your point but at this point I am not keen on
opening yet another can of worms (both technical and social) to this
already too big patch.
> Actually, before reading your patch, I thought that you aim to
> ''automatically'' create a category of "associative algebras",
> given the category of algebras and the axiom "associative".
Up to the names, that's precisely what's its doing :-)
> Hence, I think it should be
{{{
algebras
/ \
associative algebras unital algebras
\ /
associative unital algebras
}}}
What about, at least as a temporary measure, going for:
{{{
magmatic algebras
/ \
associative magmatic algebras unital magmatic algebras
\ /
algebras
}}}
(or any other not-yet-used name you like instead of "magmatic
algebra")
Cheers,
Nicolas
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:26>
Sage
-------------------------------------------------------------------------+--
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_review
Priority: major | Milestone:
Component: categories | Resolution:
Keywords: | Work issues: Rebase wrt. #13589
Report Upstream: N/A | Reviewers: Simon King
Authors: Nicolas M. Thiéry | Merged in:
Dependencies: #11224, #8327, #10193, #12895, #14516, #14722, #13589 | Stopgaps:
-------------------------------------------------------------------------+--
Comment (by SimonKing):
Replying to [comment:26 nthiery]:
> However in many textbooks and other pieces of literature
> "algebra" implicitly includes "associative" and "unital"
Certainly there also exist textbooks that will for simplicity say
"algebra" when they in fact mean "commutative algebra". But I would expect
that all these textbooks state at some point the definition of (plain)
algebras and later say that "for simplicity" or "unless stated otherwise"
they assume whatever additional axioms.
And even "better": There were times when a certain algebraic community
would only talk about ''finite'' groups. I recently heard colleagues talk
about these times. It was like "they provided generators and relations and
then needed to prove that it is a group", which in today's language is
"they provided a group presentation and needed to prove that the group is
finite".
You see: There ''are'' certain conventions peculiar to certain fields of
research.
But I think a general computer algebra system should not be biased towards
any of these peculiar conventions. Hence, it should use the "greatest
common divisor" of the notions, which is: An R-algebra is a an R-module
and a multiplicative magma, such that multiplication is R-bilinear.
> (for the same
> reason that it will be heavy for us to write almost everywhere
> Algebras().Associative().Unital()).
We can certainly have a short-cut for defining this thing.
> More importantly: changing the semantic current "Algebras" in Sage
> would be seriously backward incompatible.
Backward compatibility is indeed important. It would be difficult to
switch from Algebras in the current Sage-use to Algebras in the (I think)
normal mathematical use.
However, I ''do'' think that to the very very least we should let
`Algebras()` print as "Category of unital associative algebras".
> And we would have to think
> about what we want to do about categories like "HopfAlgebras" to keep
> things consistent.
Wikipedia does not assume associativity for algebras, but it does assume
co-associativity for co-algebras. Weird.
> So I definitely see your point but at this point I am not keen on
> opening yet another can of worms (both technical and social) to this
> already too big patch.
Concerning social: I vividly remember many talks in the séminaire
quantique in Strasbourg, entitled along the lines of "quasi-commutative
quasi-cocommutative quasi-Hopf algebras". I think ''these'' guys would be
unhappy about tacitly assuming too many axioms for algebras. And I just
checked: There also is the notion of quasi-associative algebras in
literature...
> What about, at least as a temporary measure, going for:
>
> {{{
> magmatic algebras
> / \
> associative magmatic algebras unital magmatic algebras
> \ /
> algebras
> }}}
>
> (or any other not-yet-used name you like instead of "magmatic
> algebra")
I have never heard about "magmatic algebras" before. But I have no better
idea ("plain algebras"?).
Sage-devel poll? Sage-algebra poll (although this list seems dead)? Sage-
combinat-devel poll?
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:27>
Sage
-------------------------------------------------------------------------+--
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_review
Priority: major | Milestone:
Component: categories | Resolution:
Keywords: | Work issues: Rebase wrt. #13589
Report Upstream: N/A | Reviewers: Simon King
Authors: Nicolas M. Thiéry | Merged in:
Dependencies: #11224, #8327, #10193, #12895, #14516, #14722, #13589 | Stopgaps:
-------------------------------------------------------------------------+--
Comment (by nthiery):
Replying to [comment:27 SimonKing]:
> Sage-devel poll? Sage-algebra poll (although this list seems dead)?
Sage-combinat-devel poll?
I think a CC to all three is in order in this case. I'll try to launch
the poll tomorrow.
Thanks for your work on the review!
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:28>
Sage
-------------------------------------------------------------------------+--
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_review
Priority: major | Milestone:
Component: categories | Resolution:
Authors: Nicolas M. Thiéry | Merged in:
Dependencies: #11224, #8327, #10193, #12895, #14516, #14722, #13589 | Stopgaps:
-------------------------------------------------------------------------+--
* work_issues: Rebase wrt. #13589 => Finish merging some changes in the
primer
Comment:
Patch rebased on top of #13589
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:29>
Sage
-------------------------------------------------------------------------+--
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_review
Priority: major | Milestone:
Component: categories | Resolution:
Keywords: | Work issues: Finish merging some changes in the primer
Report Upstream: N/A | Reviewers: Simon King
Authors: Nicolas M. Thiéry | Merged in:
Dependencies: #11224, #8327, #10193, #12895, #14516, #14722, #13589 | Stopgaps:
-------------------------------------------------------------------------+--
Comment (by SimonKing):
The patch applies with fuzz, but it does apply.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:30>
Sage
-------------------------------------------------------------------------+--
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_review
Priority: major | Milestone:
Component: categories | Resolution:
Keywords: | Work issues: Finish merging some changes in the primer
Report Upstream: N/A | Reviewers: Simon King
Authors: Nicolas M. Thiéry | Merged in:
Dependencies: #11224, #8327, #10193, #12895, #14516, #14722, #13589 | Stopgaps:
-------------------------------------------------------------------------+--
Comment (by SimonKing):
Why is there a double-underscore `__neg__` method as element method of
additive groups? The reason for the single underscore arithmetic methods
is, to my understanding, to enable the coercion model. But the coercion
model is not involved in the case of `__neg__`, isn't it? Hence, I think
one should keep it double underscore, and should not ask for an
implementation via a single underscore method.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:31>
Sage
-------------------------------------------------------------------------+--
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_review
Priority: major | Milestone:
Component: categories | Resolution:
Keywords: | Work issues: Finish merging some changes in the primer
Report Upstream: N/A | Reviewers: Simon King
Authors: Nicolas M. Thiéry | Merged in:
Dependencies: #11224, #8327, #10193, #12895, #14516, #14722, #13589 | Stopgaps:
-------------------------------------------------------------------------+--
Comment (by SimonKing):
Mental note: A lot of things happen when joining categories. I recall that
in some examples forming the join of categories was the reason for
slowness in algebraic constructions. Hence, we should have a look at the
speed.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:32>
Sage
-------------------------------------------------------------------------+--
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_review
Priority: major | Milestone:
Component: categories | Resolution:
Keywords: | Work issues: Finish merging some changes in the primer
Report Upstream: N/A | Reviewers: Simon King
Authors: Nicolas M. Thiéry | Merged in:
Dependencies: #11224, #8327, #10193, #12895, #14516, #14722, #13589 | Stopgaps:
-------------------------------------------------------------------------+--
Comment (by SimonKing):
I see that you define a method `_cmp_key(self)` for join categories, that
just tells that one shouldn't call it on join categories. That's bad,
because meanwhile _cmp_key is a lazy attribute (or an optimized version of
a lazy attribute), hence, it is no method anyway. Can we remove this
method?
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:33>
Sage
-------------------------------------------------------------------------+--
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_review
Priority: major | Milestone:
Component: categories | Resolution:
Keywords: | Work issues: Finish merging some changes in the primer
Report Upstream: N/A | Reviewers: Simon King
Authors: Nicolas M. Thiéry | Merged in:
Dependencies: #11224, #8327, #10193, #12895, #14516, #14722, #13589 | Stopgaps:
-------------------------------------------------------------------------+--
Comment (by SimonKing):
You ask:
{{{
# TODO: find a better way to check that cls is an abstract class
}}}
What about a class attribute? Something like
{{{
"abstract" in cls.__base__.__dict__
}}}
Or is it generally not the case that `cls.__base__` coincides with
`cls.__mro__[1]`?
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:34>
Sage
-------------------------------------------------------------------------+--
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_review
Priority: major | Milestone:
Component: categories | Resolution:
Keywords: | Work issues: Finish merging some changes in the primer
Report Upstream: N/A | Reviewers: Simon King
Authors: Nicolas M. Thiéry | Merged in:
Dependencies: #11224, #8327, #10193, #12895, #14516, #14722, #13589 | Stopgaps:
-------------------------------------------------------------------------+--
Comment (by SimonKing):
make ptest resulted in
{{{
sage -t devel/sage/sage/geometry/polyhedron/plot.py # 1 doctest failed
sage -t devel/sage/sage/categories/category.py # 3 doctests failed
sage -t devel/sage/sage/quivers/free_small_category.py # 2 doctests
failed
sage -t devel/sage/sage/categories/category_with_axiom.py # 1 doctest
failed
}}}
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:35>
Sage
-------------------------------------------------------------------------+--
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_review
Priority: major | Milestone:
Component: categories | Resolution:
Keywords: | Work issues: Finish merging some changes in the primer
Report Upstream: N/A | Reviewers: Simon King
Authors: Nicolas M. Thiéry | Merged in:
Dependencies: #11224, #8327, #10193, #12895, #14516, #14722, #13589 | Stopgaps:
-------------------------------------------------------------------------+--
Comment (by SimonKing):
I don't see why the patchbot had trouble applying the patch. Let's kick
it:
Apply trac_10963-more_functorial_constructions-nt.patch
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:36>
Sage
-------------------------------------------------------------------------+--
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_review
Priority: major | Milestone:
Component: categories | Resolution:
Keywords: | Work issues: Finish merging some changes in the primer
Report Upstream: N/A | Reviewers: Simon King
Authors: Nicolas M. Thiéry | Merged in:
Dependencies: #11224, #8327, #10193, #12895, #14516, #14722, #13589 | Stopgaps:
-------------------------------------------------------------------------+--
Comment (by SimonKing):
Replying to [comment:35 SimonKing]:
> make ptest resulted in
> {{{
> sage -t devel/sage/sage/geometry/polyhedron/plot.py # 1 doctest failed
> sage -t devel/sage/sage/categories/category.py # 3 doctests failed
> sage -t devel/sage/sage/quivers/free_small_category.py # 2 doctests
failed
> sage -t devel/sage/sage/categories/category_with_axiom.py # 1 doctest
failed
> }}}
Yes, as you can see, I have #12630 applied as well. But this only
introduces new modules, but does not interfere with old modules. Hence, I
don't think the errors come from this.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:37>
Sage
-------------------------------------------------------------------------+--
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_review
Priority: major | Milestone:
Component: categories | Resolution:
Keywords: | Work issues: Finish merging some changes in the primer
Report Upstream: N/A | Reviewers: Simon King
Authors: Nicolas M. Thiéry | Merged in:
Dependencies: #11224, #8327, #10193, #12895, #14516, #14722, #13589 | Stopgaps:
-------------------------------------------------------------------------+--
Comment (by SimonKing):
Here are the failures in detail:
The first is noise:
{{{
sage -t devel/sage/sage/geometry/polyhedron/plot.py
[178 tests, 5.55 s]
----------------------------------------------------------------------
All tests passed!
----------------------------------------------------------------------
Total time for all tests: 5.8 seconds
cpu time: 4.3 seconds
cumulative wall time: 5.6 seconds
}}}
The second:
{{{
sage -t devel/sage/sage/categories/category.py
**********************************************************************
File "devel/sage/sage/categories/category.py", line 1940, in
sage.categories.category.Category.join
Failed example:
type(TCF)
Expected:
<class
'sage.categories.category_with_axiom.TestObjects.Commutative.Facade_with_category'>
Got:
<class
'sage.categories.category_with_axiom.Commutative.Facade_with_category'>
**********************************************************************
File "devel/sage/sage/categories/category.py", line 1950, in
sage.categories.category.Category.join
Failed example:
type(TCF)
Expected:
<class
'sage.categories.category_with_axiom.TestObjects.Commutative.FiniteDimensional_with_category'>
Got:
<class
'sage.categories.category_with_axiom.Commutative.FiniteDimensional_with_category'>
**********************************************************************
File "devel/sage/sage/categories/category.py", line 1963, in
sage.categories.category.Category.join
Failed example:
type(TUCF)
Expected:
<class
'sage.categories.category_with_axiom.TestObjects.FiniteDimensional.Unital.Commutative_with_category'>
Got:
<class
'sage.categories.category_with_axiom.Unital.Commutative_with_category'>
**********************************************************************
1 item had failures:
3 of 47 in sage.categories.category.Category.join
[388 tests, 3 failures, 6.89 s]
----------------------------------------------------------------------
sage -t devel/sage/sage/categories/category.py # 3 doctests failed
----------------------------------------------------------------------
Total time for all tests: 7.3 seconds
cpu time: 6.8 seconds
cumulative wall time: 6.9 seconds
}}}
The third needs to be taken care of only if #12630 finally gets a review.
The last one:
{{{
sage -t devel/sage/sage/categories/category_with_axiom.py
**********************************************************************
File "devel/sage/sage/categories/category_with_axiom.py", line 755, in
sage.categories.category_with_axiom.CategoryWithAxiom.__reduce__
Failed example:
C.__class__
Expected:
<class
'sage.categories.distributive_magmas_and_additive_magmas.DistributiveMagmasAndAdditiveMagmas.AdditiveAssociative.AdditiveCommutative_with_category'>
Got:
<class
'sage.categories.distributive_magmas_and_additive_magmas.AdditiveAssociative.AdditiveCommutative_with_category'>
**********************************************************************
1 item had failures:
1 of 8 in
sage.categories.category_with_axiom.CategoryWithAxiom.__reduce__
[179 tests, 1 failure, 0.25 s]
}}}
So, nothing dramatic.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:38>
Sage
-------------------------------------------------------------------------+--
Reporter: nthiery | Owner: stumpc5
Component: categories | Resolution:
Authors: Nicolas M. Thiéry | Merged in:
Dependencies: #11224, #8327, #10193, #12895, #14516, #14722, #13589 | Stopgaps:
-------------------------------------------------------------------------+--
* status: needs_review => needs_work
* work_issues: Finish merging some changes in the primer => Reduce
startup time by 5%. Avoid "recursion
depth exceeded (ignored)". Trivial
doctest fixes.
Comment:
Patchbot finds
{{{
sage -t --long
/mnt/storage2TB/patchbot/Sage/sage-5.11.beta3/devel/sage/sage/rings/number_field/number_field.py
# 1 doctest failed
sage -t --long
/mnt/storage2TB/patchbot/Sage/sage-5.11.beta3/devel/sage/doc/ru/tutorial/tour_groups.rst
# 1 doctest failed
sage -t --long
/mnt/storage2TB/patchbot/Sage/sage-5.11.beta3/devel/sage/sage/geometry/polyhedron/plot.py
# 1 doctest failed
sage -t --long
/mnt/storage2TB/patchbot/Sage/sage-5.11.beta3/devel/sage/sage/categories/category.py
# 3 doctests failed
sage -t --long
/mnt/storage2TB/patchbot/Sage/sage-5.11.beta3/devel/sage/sage/categories/category_with_axiom.py
# 1 doctest failed
}}}
This sounds serious:
{{{
sage -t --long
/mnt/storage2TB/patchbot/Sage/sage-5.11.beta3/devel/sage/sage/rings/number_field/number_field.py
**********************************************************************
File
"/mnt/storage2TB/patchbot/Sage/sage-5.11.beta3/devel/sage/sage/rings/number_field/number_field.py",
line 309, in sage.rings.number_field.number_field.?
Failed example:
RR.coerce_map_from(K)
Expected:
Composite map:
From: Number Field in a with defining polynomial x^3 - 2
To: Real Field with 53 bits of precision
Defn: Generic morphism:
From: Number Field in a with defining polynomial x^3 - 2
To: Real Lazy Field
Defn: a -> 1.259921049894873?
then
Conversion via _mpfr_ method map:
From: Real Lazy Field
To: Real Field with 53 bits of precision
Got:
Exception RuntimeError: 'maximum recursion depth exceeded while
calling a Python object' in <function remove at 0x2820668> ignored
Composite map:
From: Number Field in a with defining polynomial x^3 - 2
To: Real Field with 53 bits of precision
Defn: Generic morphism:
From: Number Field in a with defining polynomial x^3 - 2
To: Real Lazy Field
Defn: a -> 1.259921049894873?
then
Conversion via _mpfr_ method map:
From: Real Lazy Field
To: Real Field with 53 bits of precision
}}}
{{{
File
"/mnt/storage2TB/patchbot/Sage/sage-5.11.beta3/devel/sage/doc/ru/tutorial/tour_groups.rst",
line 14, in doc.ru.tutorial.tour_groups
Failed example:
G = PermutationGroup(['(1,2,3)(4,5)', '(3,4)'])
Expected nothing
Got:
Exception RuntimeError: 'maximum recursion depth exceeded while
calling a Python object' in <function remove at 0xfe16e0> ignored
}}}
{{{
File
"/mnt/storage2TB/patchbot/Sage/sage-5.11.beta3/devel/sage/sage/geometry/polyhedron/plot.py",
line 461, in sage.geometry.polyhedron.plot.Projection.__init__
Failed example:
p = polytopes.icosahedron()
Expected nothing
Got:
Exception RuntimeError: 'maximum recursion depth exceeded while
getting the str of an object' in <function remove at 0x2e03e60> ignored
Exception RuntimeError: 'maximum recursion depth exceeded while
getting the str of an object' in <function remove at 0x2e03e60> ignored
}}}
And the result of the startup time plugin is also a bad news.
{{{
+Average increase of 0.057 secs or 8.1%.
+With 100% confidence, startup time increased by at least 5%
+With 100% confidence, startup time increased by at least 2.5%
+With 100% confidence, startup time increased by at least 1%
+With 100% confidence, startup time increased by at least 0.5%
+With 100% confidence, startup time increased by at least 0.25%
}}}
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:39>
Sage
-------------------------------------------------------------------------+--
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_work
Priority: major | Milestone:
Component: categories | Resolution:
Keywords: | Work issues: Reduce startup time by 5%. Avoid "recursion depth exceeded (ignored)". Trivial doctest fixes.
Report Upstream: N/A | Reviewers: Simon King
Authors: Nicolas M. Thiéry | Merged in:
Dependencies: #11224, #8327, #10193, #12895, #14516, #14722, #13589 | Stopgaps:
-------------------------------------------------------------------------+--
Comment (by SimonKing):
There is a naked
{{{
assert False
}}}
in `sage.categories.category.Category.__init__`, followed(!) by a
deprecation warning. How can the warning ever appear after asserting a
false statement?
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:40>
Sage
-------------------------------------------------------------------------+--
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_work
Priority: major | Milestone:
Component: categories | Resolution:
Keywords: | Work issues: Reduce startup time by 5%. Avoid "recursion depth exceeded (ignored)". Trivial doctest fixes.
Report Upstream: N/A | Reviewers: Simon King
Authors: Nicolas M. Thiéry | Merged in:
Dependencies: #11224, #8327, #10193, #12895, #14516, #14722, #13589 | Stopgaps:
-------------------------------------------------------------------------+--
Comment (by SimonKing):
I have a question on how to implement a new category with support of
axioms.
If I understand correctly, the method `_with_axiom_categories` tells which
categories need to be added to self in order to get the category with the
axiom added. Is one supposed to overload this method? Sorry, I did not
read your patch completely yet. Is this question answered somewhere? If
not, I think it must be added to a tutorial.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:41>
Sage
-------------------------------------------------------------------------+--
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_work
Priority: major | Milestone:
Component: categories | Resolution:
Keywords: | Work issues: Reduce startup time by 5%. Avoid "recursion depth exceeded (ignored)". Trivial doctest fixes.
Report Upstream: N/A | Reviewers: Simon King
Authors: Nicolas M. Thiéry | Merged in:
Dependencies: #11224, #8327, #10193, #12895, #14516, #14722, #13589 | Stopgaps:
-------------------------------------------------------------------------+--
Comment (by SimonKing):
Here is some cryptic phrase from category_with_axiom:
{{{
The later two are implemented using respectively
:meth:`__classcall__` and :meth:`__classget__` which see.
}}}
It ends in the middle of the phrase.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:42>
Sage
-------------------------------------------------------------------------+--
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_work
Priority: major | Milestone:
Component: categories | Resolution:
Keywords: | Work issues: Reduce startup time by 5%. Avoid "recursion depth exceeded (ignored)". Trivial doctest fixes.
Report Upstream: N/A | Reviewers: Simon King
Authors: Nicolas M. Thiéry | Merged in:
Dependencies: #11224, #8327, #10193, #12895, #14516, #14722, #13589 | Stopgaps:
-------------------------------------------------------------------------+--
Comment (by SimonKing):
I try to summarize how I understand how the patch works---so, please
correct me if I misunderstood.
Generally, adding an axiom A to a category C means: Forming the join of C
with `C._with_axiom_categories(A)`, unless there is a class
`getattr(C,A)`, for example: `Magmas().Associative` is `Semigroups`. The
categories returned by `C._with_axiom_categories(A)` would, for example,
provide new parent and element methods (such as: `prod()` only makes sense
in an associative magma, `_test_one()` only makes sense for unital
magmas).
If I understand correctly, the same "axiom category" (here:
`Magmas.Associative`) is available to all subcategories of `Magmas()`,
because it is defined in `Magmas.SubcategoryMethods`. Or am I mistaken and
it is ''not'' the same? Is another dynamic class involved here? This could
also give rise to slowness.
Apart from hard-coded cases, the rôle of `JoinCategory` has generally
increased, and this indicates it might make sense to spend some
optimization there. A highly significant increase of at least 5% of
startup time is rather much. I don't know if `JoinCategory` is the only
problem here.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:43>
Sage
-------------------------------------------------------------------------+--
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_work
Priority: major | Milestone:
Component: categories | Resolution:
Keywords: | Work issues: Reduce startup time by 5%. Avoid "recursion depth exceeded (ignored)". Trivial doctest fixes.
Report Upstream: N/A | Reviewers: Simon King
Authors: Nicolas M. Thiéry | Merged in:
Dependencies: #11224, #8327, #10193, #12895, #14516, #14722, #13589 | Stopgaps:
-------------------------------------------------------------------------+--
Comment (by SimonKing):
If I understand correctly, the reason for creating a `JoinCategory` is to
get the correct supercategories. But there are alternative ways to get the
supercategories right. I could imagine to use a dynamic class instead. So,
the aim of this post is to present an alternative approach that avoids
joins.
If C is a category and one wants to have `C.MyAxiom()`, then I suggest to
create a dynamic class `cls` out of `C.__class__` (and perhaps also using
the class `C.MyAxiom`?), and set a ''class'' attribute `cls._used_axioms`
which is a (frozen) set formed by `C.__class__._used_axioms` and
`"MyAxiom"`.
Note: The order in which the axioms are given should not matter. Hence,
the way of caching the dynamic class should be: By a class that has no
axioms, and by `C.__class__._used_axioms`.
We would like to call `cls` with the same `__init__` arguments that were
used for creating `C`. So, how to get the init data? No problem, since `C`
uses `UniqueRepresentation`!. For example:
{{{
sage: C = Bimodules(ZZ, QQ)
sage: C._reduction
(sage.categories.bimodules.Bimodules, (Integer Ring, Rational Field), {})
}}}
So, `C.MyAxiom()` would eventually do something like this
{{{
cls = dynamic_class("MyAxiom"+C.__class__.__name__, (C.__class__,
C.MyAxiom), C.__class__, <take care of caching>)
return cls(*(C._reduction[1][0]), **(C._reduction[1][1]))
}}}
Note that by way of caching the dynamic class, I guess the above would
automatically cover the corner case that `C.__class__._used_axioms`
contains `"MyAxiom"`. Namely, in this case, `cls is C.__class__` by means
of caching the dynamic class, and then `cls(*..., **...)` coincides with
C, since it is a `UniqueRepresentation`.
By means of explicitly overloading the cache of the dynamic class, one
could even ensure that `DivisionRings.Finite()` returns `Fields.Finite()`,
I guess.
Let's denote `C2=C.MyAxiom()`. And then, the critical question is: How to
determine the super categories of `C2`?
I guess for each axiom `A in C2.__class__._used_axioms`, we want to return
`C2._without_axiom(A)`, and we want to return `D._with_axiom(A)` for all
`D` is in `C2._without_axiom(A).super_categories()`, of course removing
duplicates.
So, there only remains to answer: What is `C2._without_axiom(A)`?
Again, we can use `C2._reduction` to get the input data, but how to get
the class of `D=C2._without_axiom(A)`? Note that `C2` might have several
axioms, and we do ''not'' order the axioms.
However, we know what `D.__class__._used_axioms` is supposed to look like:
It is `C2.__class__._used_axiom.difference("MyAxiom")`.
Thus, we get something like this:
{{{
@cached_method
def _without_axiom(self, axiom):
if axiom not in self.__class__._used_axioms:
<raise some error>
new_axioms = self.__class__._used_axioms.difference([axiom])
for cls in self.__class__.__mro__:
if getattr(cls, "_used_axioms", None) == new_axioms:
break
if cls is object:
<raise some error>
return cls(*(self._reduction[1][0]), **(self._reduction[1][1]))
}}}
Do you think this would make sense?
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:44>
Sage
-------------------------------------------------------------------------+--
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_work
Priority: major | Milestone:
Component: categories | Resolution:
Keywords: | Work issues: Reduce startup time by 5%. Avoid "recursion depth exceeded (ignored)". Trivial doctest fixes.
Report Upstream: N/A | Reviewers: Simon King
Authors: Nicolas M. Thiéry | Merged in:
Dependencies: #11224, #8327, #10193, #12895, #14516, #14722, #13589 | Stopgaps:
-------------------------------------------------------------------------+--
Comment (by nthiery):
Replying to [comment:38 SimonKing]:
> {{{
> sage -t devel/sage/sage/categories/category.py
> **********************************************************************
> File "devel/sage/sage/categories/category.py", line 1940, in
sage.categories.category.Category.join
> Failed example:
> type(TCF)
> Expected:
> <class
'sage.categories.category_with_axiom.TestObjects.Commutative.Facade_with_category'>
> Got:
> <class
'sage.categories.category_with_axiom.Commutative.Facade_with_category'>
}}}
Ah yes, good point: I have #9107 in my queue. So we will have to
either add it as a dependency if it gets ready soon, or update the
doctests. As you point out, nothing dramatic.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:45>
Sage
-------------------------------------------------------------------------+--
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_work
Priority: major | Milestone:
Component: categories | Resolution:
Keywords: | Work issues: Reduce startup time by 5%. Avoid "recursion depth exceeded (ignored)". Trivial doctest fixes.
Report Upstream: N/A | Reviewers: Simon King
Authors: Nicolas M. Thiéry | Merged in:
Dependencies: #11224, #8327, #10193, #12895, #14516, #14722, #13589 | Stopgaps:
-------------------------------------------------------------------------+--
Comment (by nthiery):
Replying to [comment:31 SimonKing]:
> Why is there a double-underscore `__neg__` method as element method of
additive groups? The reason for the single underscore arithmetic methods
is, to my understanding, to enable the coercion model. But the coercion
model is not involved in the case of `__neg__`, isn't it? Hence, I think
one should keep it double underscore, and should not ask for an
implementation via a single underscore method.
All I did is to lift this method from
"sage.structure.element.ModuleElement", as a step toward deprecating this
class.
I agree that the _neg_ feature itself is questionable (it has no purpose
besides consistency). So one could think about removing it (and fixing the
couple modules in Sage that implement _neg_). But that would require a
discussion on sage-devel and is in any cases for a different ticket.
For this ticket, do you think I should add a little comment about this in
the doc?
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:46>
Sage
-------------------------------------------------------------------------+--
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_work
Priority: major | Milestone:
Component: categories | Resolution:
Keywords: | Work issues: Reduce startup time by 5%. Avoid "recursion depth exceeded (ignored)". Trivial doctest fixes.
Report Upstream: N/A | Reviewers: Simon King
Authors: Nicolas M. Thiéry | Merged in:
Dependencies: #11224, #8327, #10193, #12895, #14516, #14722, #13589 | Stopgaps:
-------------------------------------------------------------------------+--
Comment (by nthiery):
Hi Simon!
Thanks for all your work on the review of this ticket! I am currently
on vacations, so my answers might be slow.
Replying to [comment:44 SimonKing]:
> If I understand correctly, the reason for creating a `JoinCategory`
> is to get the correct supercategories.
The reason to call "join" is indeed to get the correct supercategories
for {{{C.MyAxiom()}}}. Note that, on the other hand and unless I
screwed up somewhere, there should be no {{{JoinCategory}}} produced
(unless of course the end result of {{{C.MyAxiom()}}} itself is such a
{{{JoinCategory}}}).
> But there are alternative ways to get the supercategories right. I
> could imagine to use a dynamic class instead. So, the aim of this
> post is to present an alternative approach that avoids joins.
In general, I agree that joins are called quite often and it would be
nice to optimize them and/or call them less often. However, I think we
really want to call a join to get the full power of the
architecture. Imagine for example that:
- C is a super category of A and B
- {{{A.MyAxiom()}}} implies {{{A.MyOtherAxiom()}}}
- {{{B.MyOtherAxiom()}}} is non trivial
Then we want {{{C.MyAxiom().super_categories()}}} to automatically
include {{{B.MyOtherAxiom()}}}, for otherwise we would need to
basically replicate the information that {{{A.MyAxiom()}}} implies
{{{A.MyOtherAxiom()}}} over and over in subcategories, and this would
not scale.
Handling this kind of stuff is precisely the core of the logic in
``join``. So if you see a way to optimize the computation of the super
categories of {{{C.MyAxiom()}}} while preserving the above feature,
then I believe you actually have found a way to optimize ``join`` in
the first place.
Cheers,
Nicolas
PS: let's keep in mind this idea of using the reduction. It could indeed
be that it could be used in a place or two to simplify the logic.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:47>
Sage
-------------------------------------------------------------------------+--
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_work
Priority: major | Milestone:
Component: categories | Resolution:
Keywords: | Work issues: Reduce startup time by 5%. Avoid "recursion depth exceeded (ignored)". Trivial doctest fixes.
Report Upstream: N/A | Reviewers: Simon King
Authors: Nicolas M. Thiéry | Merged in:
Dependencies: #11224, #8327, #10193, #12895, #14516, #14722, #13589 | Stopgaps:
-------------------------------------------------------------------------+--
Comment (by SimonKing):
Replying to [comment:47 nthiery]:
> Thanks for all your work on the review of this ticket! I am currently
> on vacations, so my answers might be slow.
So am I. Perhaps I can try to provide a proof of concept, IF I manage to
deal with the scenario that you mentioned.
Have nice holidays!
Simon
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:48>
Sage
-------------------------------------------------------------------------+--
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_work
Priority: major | Milestone:
Component: categories | Resolution:
Keywords: | Work issues: Reduce startup time by 5%. Avoid "recursion depth exceeded (ignored)". Trivial doctest fixes.
Report Upstream: N/A | Reviewers: Simon King
Authors: Nicolas M. Thiéry | Merged in:
Dependencies: #11224, #8327, #10193, #12895, #14516, #14722, #13589 | Stopgaps:
-------------------------------------------------------------------------+--
Comment (by SimonKing):
Replying to [comment:47 nthiery]:
> The reason to call "join" is indeed to get the correct supercategories
> for {{{C.MyAxiom()}}}. Note that, on the other hand and unless I
> screwed up somewhere, there should be no {{{JoinCategory}}} produced
> (unless of course the end result of {{{C.MyAxiom()}}} itself is such a
> {{{JoinCategory}}}).
Really? So, then I was mislead by a couple of doctests that demonstrate
that a certain category is in fact a join category, even though it is not
printed as such, and also mislead by the code that uses
`self._with_axiom_categories(...)`, which I thought does in fact form a
join.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:49>
Sage
-------------------------------------------------------------------------+--
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_work
Priority: major | Milestone:
Component: categories | Resolution:
Keywords: | Work issues: Reduce startup time by 5%. Avoid "recursion depth exceeded (ignored)". Trivial doctest fixes.
Report Upstream: N/A | Reviewers: Simon King
Authors: Nicolas M. Thiéry | Merged in:
Dependencies: #11224, #8327, #10193, #12895, #14516, #14722, #13589 | Stopgaps:
-------------------------------------------------------------------------+--
Comment (by SimonKing):
Hi Nicolas,
Replying to [comment:47 nthiery]:
> - C is a super category of A and B
> - {{{A.MyAxiom()}}} implies {{{A.MyOtherAxiom()}}}
> - {{{B.MyOtherAxiom()}}} is non trivial
I suppose you mean: C is a sub-category of A and B.
__What is an axiom?__
First of all, I wonder if we have the same understanding of "axiom". For
me, an axiom is defined in terms of an algebraic structure that is
provided by a certain category without this axiom. In particular
`A.Associative()` is actually not well-defined: One should in theory have
`A.MultiplicativeAssociative()`, where `MultiplicativeAssociative` is
provided by `Magmas()`, or `A.AdditiveAssociative()`, where
`AdditiveAssociative` is provided by `AdditiveMagmas()`.
Granted, if `A=Algebras(ZZ)`, then `A.Associative()` should be synonym of
`A.MultiplicativeAssociative()`. So, we might want to introduce reasonable
short-cuts in some cases.
__Your Example__
Now, in your example, if `MyAxiom` is defined for both A and B, then the
meet of A and B is a sub-category of a category M, for which `MyAxiom` and
`MyOtherAxiom` are defined. In your example, `MyAxiom` implies
`MyOtherAxiom` for A but not for B. Hence, A can be written as a sub-
category of `M.SpecialAxiom()`, and `SpecialAxiom` together with `MyAxiom`
implies `MyOtherAxiom`.
Now, you consider a category C defined by `C.__class__(data)`, which is a
common sub-category of A and B, and you wonder about the super-categories
of `C.MyAxiom()`.
Since A satisfies `SpecialAxiom`, C satisfies it as well. Hence, `D =
C.MyAxiom()`will also satisfy `MyOtherAxiom`. I guess the logic of this
implication is encoded in the way how `D.__class__._used_axioms` is
determined. Hence, `D.__class__._used_axioms` contains `SpecialAxiom`,
`MyAxiom` ''and'' `MyOtherAxiom`.
In a previous post, I presented an algorithm for determining
`D.super_categories()`. Let us study what it will return. Recall that it
returns `D._without_axiom(axiom)` for all axiom in
`D.__class__._used_axioms`, after removing duplicates. Hence:
- `axiom=SpecialAxiom`: We go along the mro of `D.__class__` until we find
something that does not have `SpecialAxiom`. This will be a certain super-
category X of C that is a sub-category of B (supposing that B does not
satisfy `SpecialAxiom`). This will result in
`X....MyAxiom().MySpecialAxiom()`, applying all axioms (except
`SpecialAxiom`) that hold for D but not for X.
- `axiom=MyAxiom`: This will yield `C.MyOtherAxiom()`.
- `axiom=MyOtherAxiom`: This will yield `C.MyAxiom()`, which coincides
with D and is thus removed as a duplicate.
Note that in this explanation I have modified my previous suggestion for
`D._without_axiom(this_axiom)`: We can not expect that
`D.__class__.__mro__` provides something that has ''the same'' axioms than
D, with just `this_axiom` omitted. But since applying axioms commutes, it
is fine to take ''the first'' class in `D.__class__.__mro__` that does not
have `this_axiom`, and then create a category from this class (with the
known input data of D), and apply all other missing axioms.
Anyway, I think that the above answer to `C.MyAxiom().super_categories()`
looks fine. Or what else would you like to have?
Cheers,
Simon
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:50>
Sage
-------------------------------------------------------------------------+--
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_work
Priority: major | Milestone:
Component: categories | Resolution:
Keywords: | Work issues: Reduce startup time by 5%. Avoid "recursion depth exceeded (ignored)". Trivial doctest fixes.
Report Upstream: N/A | Reviewers: Simon King
Authors: Nicolas M. Thiéry | Merged in:
Dependencies: #11224, #8327, #10193, #12895, #14516, #14722, #13589 | Stopgaps:
-------------------------------------------------------------------------+--
Comment (by SimonKing):
I guess I should re-think the above in a more concrete scenario. Let `D =
DivisionRings()`. What do we do with `D.Finite()`?
Would we agree on `D = Rings().WithMultiplicativeInverses()`? I guess we
would obtain `Fields()=D.Commutative()`. So, as in the situation above, we
have the rule that if `WithMultiplicativeInverses()` is applied to
`Rings()`, then the additional axiom `Finite()` implies the axiom
`Commutative()`.
Hence, `D.Finite()` yields `Fields().Finite()=FiniteFields()`. To be
discussed: Should this be created dynamically, or should there be a hard-
coded separate class definition?
So, what would `FiniteFields().super_categories()` return by the algorithm
I presented above?
- Omit `Commutative`: We still have the axioms
`WithMultiplicativeInverses` and `Finite`, hence, we recover
`FiniteFields()`, which is thus a duplicate and not part of
`FiniteFields().super_categories()`.
- Omit `Finite`: The remaining axioms are those of commutative division
rings, which yields `Fields()`.
- Omit `WithMultiplicativeInverses`: Yields finite commutative rings.
So, `FiniteFields().super_categories()`returns `[Fields(),
Rings().Commutative().Finite()]`. Do you think this answer makes sense?
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:51>
Sage
-------------------------------------------------------------------------+--
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_work
Priority: major | Milestone:
Component: categories | Resolution:
Keywords: | Work issues: Reduce startup time by 5%. Avoid "recursion depth exceeded (ignored)". Trivial doctest fixes.
Report Upstream: N/A | Reviewers: Simon King
Authors: Nicolas M. Thiéry | Merged in:
Dependencies: #11224, #8327, #10193, #12895, #14516, #14722, #13589 | Stopgaps:
-------------------------------------------------------------------------+--
Comment (by SimonKing):
Replying to [comment:51 SimonKing]:
> So, `FiniteFields().super_categories()`returns `[Fields(),
Rings().Commutative().Finite()]`. Do you think this answer makes sense?
Actually I'd like this answer more than the current answers.
Without your patch:
{{{
sage: FiniteFields().super_categories()
[Category of fields, Category of finite enumerated sets]
}}}
With your patch:
{{{
sage: FiniteFields().super_categories()
[Category of fields, Category of finite monoids]
}}}
It seems to me that
{{{
sage: FiniteFields().super_categories()
[Category of fields, Category of finite commutative rings]
}}}
would be more accurate.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:52>
Sage
-------------------------------------------------------------------------+--
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_work
Priority: major | Milestone:
Component: categories | Resolution:
Keywords: | Work issues: Reduce startup time by 5%. Avoid "recursion depth exceeded (ignored)". Trivial doctest fixes.
Report Upstream: N/A | Reviewers: Simon King
Authors: Nicolas M. Thiéry | Merged in:
Dependencies: #11224, #8327, #10193, #12895, #14516, #14722, #13589 | Stopgaps:
-------------------------------------------------------------------------+--
Comment (by nthiery):
Replying to [comment:52 SimonKing]:
> It seems to me that
> {{{
> sage: FiniteFields().super_categories()
> [Category of fields, Category of finite commutative rings]
> }}}
> would be more accurate.
But this would mean constructing a trivial category for finite commutative
rings (there is currently no category code for finite commutative rings).
The point of the axioms infrastructure is precisely to avoid such trivial
categories in the category hierarchy in order to prevent the potential
combinatorial explosion.
Besides: should this be finite commutative rings? Or finite domains? Or
finite euclidean rings? ...
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:53>
Sage
-------------------------------------------------------------------------+--
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_work
Priority: major | Milestone:
Component: categories | Resolution:
Keywords: | Work issues: Reduce startup time by 5%. Avoid "recursion depth exceeded (ignored)". Trivial doctest fixes.
Report Upstream: N/A | Reviewers: Simon King
Authors: Nicolas M. Thiéry | Merged in:
Dependencies: #11224, #8327, #10193, #12895, #14516, #14722, #13589 | Stopgaps:
-------------------------------------------------------------------------+--
Comment (by SimonKing):
Replying to [comment:53 nthiery]:
>
> But this would mean constructing a trivial category for finite
commutative rings (there is currently no category code for finite
commutative rings).
That's the point: In my approach, this category would be constructed on
the fly, by means of a dynamic construction.
> Besides: should this be finite commutative rings? Or finite domains? Or
finite euclidean rings? ...
To be discussed. In the end of the day, this is a matter of what axioms we
have for fields that do not hold for all division rings, and which are
thus implied by adding `Finite()` to `Rings().Division()`.
However, I do think that the category of finite commutative rings should
be a super-category of the category of finite fields. But (with your
patch):
{{{
sage: Rings().Finite() in Fields().Finite().all_super_categories()
False
}}}
even though
{{{
sage: (Fields().Finite()).is_subcategory(Rings().Finite())
True
}}}
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:54>
Sage
-------------------------------------------------------------------------+--
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_work
Priority: major | Milestone:
Component: categories | Resolution:
Keywords: | Work issues: Reduce startup time by 5%. Avoid "recursion depth exceeded (ignored)". Trivial doctest fixes.
Report Upstream: N/A | Reviewers: Simon King
Authors: Nicolas M. Thiéry | Merged in:
Dependencies: #11224, #8327, #10193, #12895, #14516, #14722, #13589 | Stopgaps:
-------------------------------------------------------------------------+--
Comment (by nthiery):
Replying to [comment:50 SimonKing]:
> I suppose you mean: C is a sub-category of A and B.
Oops, yes, sure.
> __What is an axiom?__
>
> First of all, I wonder if we have the same understanding of "axiom". For
me, an axiom is defined in terms of an algebraic structure that is
provided by a certain category without this axiom.
Yes.
> In particular `A.Associative()` is actually not well-defined: One should
in theory have `A.MultiplicativeAssociative()`, where
`MultiplicativeAssociative` is provided by `Magmas()`, or
`A.AdditiveAssociative()`, where `AdditiveAssociative` is provided by
`AdditiveMagmas()`.
> Granted, if `A=Algebras(ZZ)`, then `A.Associative()` should be synonym
of `A.MultiplicativeAssociative()`. So, we might want to introduce
reasonable short-cuts in some cases.
Of course. But that would be heavy and require to have an
infrastructure for shortcuts. So I just followed the previously set
convention (as in CommutativeRings w.r.t CommutativeAdditiveMonoids):
by default, the associative/commutative/unital/... axioms are about
the multiplicative structure, and I think that's ok.
> __Your Example__
>
> Now, in your example, if `MyAxiom` is defined for both A and B, then the
meet of A and B is a sub-category of a category M, for which `MyAxiom` and
`MyOtherAxiom` are defined. In your example, `MyAxiom` implies
`MyOtherAxiom` for A but not for B. Hence, A can be written as a sub-
category of `M.SpecialAxiom()`, and `SpecialAxiom` together with `MyAxiom`
implies `MyOtherAxiom`.
>
> Now, you consider a category C defined by `C.__class__(data)`, which is
a common sub-category of A and B, and you wonder about the super-
categories of `C.MyAxiom()`.
>
> Since A satisfies `SpecialAxiom`, C satisfies it as well. Hence, `D =
C.MyAxiom()`will also satisfy `MyOtherAxiom`. I guess the logic of this
implication is encoded in the way how `D.__class__._used_axioms` is
determined. Hence, `D.__class__._used_axioms` contains `SpecialAxiom`,
`MyAxiom` ''and'' `MyOtherAxiom`.
>
> In a previous post, I presented an algorithm for determining
`D.super_categories()`. Let us study what it will return. Recall that it
returns `D._without_axiom(axiom)` for all axiom in
`D.__class__._used_axioms`, after removing duplicates. Hence:
> - `axiom=SpecialAxiom`: We go along the mro of `D.__class__` until we
find something that does not have `SpecialAxiom`. This will be a certain
super-category X of C that is a sub-category of B (supposing that B does
not satisfy `SpecialAxiom`). This will result in
`X....MyAxiom().MySpecialAxiom()`, applying all axioms (except
`SpecialAxiom`) that hold for D but not for X.
> - `axiom=MyAxiom`: This will yield `C.MyOtherAxiom()`.
> - `axiom=MyOtherAxiom`: This will yield `C.MyAxiom()`, which coincides
with D and is thus removed as a duplicate.
>
> Note that in this explanation I have modified my previous suggestion for
`D._without_axiom(this_axiom)`: We can not expect that
`D.__class__.__mro__` provides something that has ''the same'' axioms than
D, with just `this_axiom` omitted. But since applying axioms commutes, it
is fine to take ''the first'' class in `D.__class__.__mro__` that does not
have `this_axiom`, and then create a category from this class (with the
known input data of D), and apply all other missing axioms.
>
> Anyway, I think that the above answer to
`C.MyAxiom().super_categories()` looks fine. Or what else would you like
to have?
Honestly I don't have the time to check all the details. If you
believe that computing A.Axiom() is intrinsically simpler than
computing a join (I don't and would favor optimizing join instead),
feel free to write a prototype. The test suite in
category_with_axiom.py should be a good guide. Just be warned that it
took me a good two weeks of solid work to get things right, and that
after at least two iterations :-)
Enjoy your vacations too!
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:55>
Sage
-------------------------------------------------------------------------+--
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_work
Priority: major | Milestone:
Component: categories | Resolution:
Keywords: | Work issues: Reduce startup time by 5%. Avoid "recursion depth exceeded (ignored)". Trivial doctest fixes.
Report Upstream: N/A | Reviewers: Simon King
Authors: Nicolas M. Thiéry | Merged in:
Dependencies: #11224, #8327, #10193, #12895, #14516, #14722, #13589 | Stopgaps:
-------------------------------------------------------------------------+--
Comment (by nthiery):
Replying to [comment:54 SimonKing]:
> Replying to [comment:53 nthiery]:
> >
> > But this would mean constructing a trivial category for finite
commutative rings (there is currently no category code for finite
commutative rings).
>
> 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.
And that many for additive magmas.
> To be discussed. In the end of the day, this is a matter of what
> axioms we have for fields that do not hold for all division rings,
> and which are thus implied by adding `Finite()` to
> `Rings().Division()`.
Note that this is currently resolved automatically by the current
mechanism by looking which axioms are defined/implemented by the
various categories.
> However, I do think that the category of finite commutative rings should
be a super-category of the category of finite fields. But (with your
patch):
> {{{
> sage: Rings().Commutative().Finite() in
Fields().Finite().all_super_categories()
> False
> }}}
> even though
> {{{
> sage: (Fields().Finite()).is_subcategory(Rings().Commutative().Finite())
> True
> }}}
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.
Cheers,
Nicolas
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:56>