Opened 11 months ago
Last modified 4 months ago
#30233 new enhancement
Axioms FinitelyGenerated, FinitelyGeneratedAs....
Reported by:  mkoeppe  Owned by:  

Priority:  major  Milestone:  sage9.4 
Component:  categories  Keywords:  
Cc:  tscrim, nthiery, heluani  Merged in:  
Authors:  Reviewers:  
Report Upstream:  N/A  Work issues:  
Branch:  public/finitely_generated_as_xxx_axioms (Commits, GitHub, GitLab)  Commit:  2cf761420fbb107622a8febb4c6a88d1c4493fd9 
Dependencies:  Stopgaps: 
Description
sage: CR = CommutativeRings() sage: CR.FinitelyGenerated() ValueError: FinitelyGenerated is ambiguous for Category of commutative rings. Please use explicitly one of the FinitelyGeneratedAsXXX methods
However, there is only one such method: FinitelyGeneratedAsMagma
.
Also:
sage: Modules(QQ).FinitelyGenerated() AttributeError: 'VectorSpaces_with_category' object has no attribute 'FinitelyGenerated'
Change History (17)
comment:1 followups: ↓ 2 ↓ 7 Changed 11 months ago by
comment:2 in reply to: ↑ 1 ; followups: ↓ 3 ↓ 4 Changed 11 months ago by
Replying to heluani:
I've implemented three more with
FinitelyGeneratedAsLieConformalAlgebra
,FinitelyGeneratedAsVertexAlgebra
andFinitelyGeneratedAsPoissonVertexAlgebra
I think it's only a matter of time until people (like me) are drawn to Sage and start implementing more.
Yes, I saw them on your tickets, hence the cc.
For
Modules(QQ)
this was probably left intentionally like this. I can see a few reasons for this, since for modules over ak
algebraR
,FiniteDimensional
means typically finite dimensional overk
, it could be very confusing/tricky to have amodules.SubcategoryMethods.FinitelyGenerated
.
Maybe this example just provides an indication that FinitelyGenerated
should not be a subcategory method.
For modules, I would like the category system to infer that Modules(R).WithBasis().FinitelyGenerated() is Modules(R).FiniteDimensional()
, for example.
comment:3 in reply to: ↑ 2 Changed 11 months ago by
Maybe this example just provides an indication that
FinitelyGenerated
should not be a subcategory method.
Having it as a subcategory method is certainly an abuse. Back then, my decision to do this abuse was:
 It really is meant as userlevel syntactic sugar. Code or anyone wanting math reliability should use the long versions
 It would be a pain to define FinitelyGenerated? for all the variants of AdditiveMagmas? and Magmas (e.g. (additive) semigroups, monoids, groups, finite or not, J/L/Rtrivial or note, etc.
Maybe it should just not exist.
comment:4 in reply to: ↑ 2 ; followup: ↓ 5 Changed 11 months ago by
For modules, I would like the category system to infer that
Modules(R).WithBasis().FinitelyGenerated() is Modules(R).FiniteDimensional()
, for example.
This should be doable with Modules.WithBasis.FinitelyGenerated_extra_super_categories
returning Modules(R).FiniteDimensional()
.
(note: Modules(R).WithBasis().FinitelyGenerated()
won't be Modules(R).FiniteDimensional()
but Modules(R).WithBasis().FiniteDimensional()
).
All of this said after not playing with categories for a long while. So take it with a grain of salt! In any case, I am super glad this is being extended and getting further attention.
comment:5 in reply to: ↑ 4 Changed 11 months ago by
Replying to nthiery:
For modules, I would like the category system to infer that
Modules(R).WithBasis().FinitelyGenerated() is Modules(R).FiniteDimensional()
, for example.This should be doable with
Modules.WithBasis.FinitelyGenerated_extra_super_categories
returningModules(R).FiniteDimensional()
.
Thanks! I'll try this.
(note:
Modules(R).WithBasis().FinitelyGenerated()
won't beModules(R).FiniteDimensional()
butModules(R).WithBasis().FiniteDimensional()
).
Right, that's what I meant.
comment:6 Changed 11 months ago by
By the way, I am trying to figure out what exactly is meant by the category Modules(R).FiniteDimensional()
. Is this intended to be imply "free" already?
comment:7 in reply to: ↑ 1 Changed 11 months ago by
Replying to heluani:
for modules over a
k
algebraR
,FiniteDimensional
means typically finite dimensional overk
, it could be very confusing/tricky to have amodules.SubcategoryMethods.FinitelyGenerated
.
Reimundo explained it above  but then (1) should Modules(R).FiniteDimensional()
be defined at all if R
is not an algebra over a field?
Also, (2) the category system does not seem to know about it:
sage: QQ['x'] in Algebras(QQ) True sage: Modules(QQ['x']).FiniteDimensional() & Modules(QQ) Join of Category of finite dimensional modules over Rational Field and Category of finite dimensional modules over Univariate Polynomial Ring in x over Rational Field and Category of vector spaces over Rational Field
comment:8 Changed 11 months ago by
I am not sure why I am not getting emails from most trac tickets that I am cc'd but from some I do (I missed this conversation for example).
There is a WARNING
block in the code for modules.
Outside of the context of symmetric modules over a commutative ring, the specifications of this category are fuzzy and not yet set in stone (see below). The code in this category and its subcategories is therefore prone to bugs or arbitrary limitations in this case.
Which probably covers this. By browsing at the code in modules and modules with basis it looks to me that every method that is implemented works if FiniteDimensional
just means "Finitely generated and free" as an R
module.
I do not think that anything in the category files for modules refers to any of the list of probable definition of "dimension" for a module over an arbitrary ring (like "Krull" dimension for modules over a commutative ring, or globa dimension, projective dimension, etc. in other contexts)
Since nothing is really implemented under the class Modules.FiniteDimensional
besides the fact that a finite dimensional module over a finite ring is finite. It seems to me that all implemented methods are in Modules.WithBasis.FiniteDimensional
which implies they are Free modules.
comment:9 followup: ↓ 10 Changed 10 months ago by
I wanted to ask you your opinion on something. Since this has come up in the Lie Conformal Algebras ticket #30032 comment 30 and I suppose eventually this should scale correctly.
I think that whatever category of parents Cs()
where there is a natural notion of finitely generated object, this should be implemented as Cs().FinitelyGenerated()
. Here by natural I mean that no mathematician would be confused. A prototypical example is Rings()
. Of course one can think of a ring which is finitely generated as an additive magma, but in this case this would be explicit, when we simply say R
is finitely generated we mean that every element of R
can be written as a sum of elements of the form a_1 a_2...a_n
for a_i
in a finite set of generators.
Now on the other hand it seems ridiculous to implement axioms FinitelyGeneratedAs*
for *
meaning an algebra over closely related operads. This does not scale correctly and eventually we will end up with a lot of axioms in category_with_axiom.py
. So I suggest we implement at least these two generic axioms:
 For objects that are both a (multiplicative) magma and an additive magma and is distributive, implement something like
FinitelyGeneratedAsDistributiveMagmas
which means every element is written as sums of elements of the forma_1...a_n
but now parenthesis are put anywhere.
 For objects as in 1. but in an
R
linear category, that is they areR
modules and they have anR
bilinear operation*
such that the sum is distributive. Then implementFinitelyGeneratedAsDistributiveAlgebras
(perhaps a more generic name is in order and this is unfortunate that algebra means associative in Sage) to mean exactly as above but instead of sums, linear combinations with coefficients inR
.
Then for example Rings().FinitelyGenerated()
should call FinitelyGeneratedAsDistributiveMagmas
while LieAlgebras().FinitelyGenerated()
and Algebras(QQ).FinitelyGenerated()
for example should call FinitelyGeneratedAsDistributiveAlgebras
.
I can see also a lot of uses for a third option
 Objects as in 2. but with a derivation
D
of the operation*
over the ringR
. In this case we can implementFinitelyGeneratedAsDifferentialAlgebra
(again different name because differential nowadays means with a differential not like Ritt's original definition) Then for example all my three objectsLieConformalAlgebras
,VertexAlgebras
andPoissonVertexAlgebras
would call the same axiomFinitelyGeneratedAsDifferentialAlgebra
instead of having to implement three of them.
This post came to mind because Travis is suggesting in #30032 to implement something like FinitelyGeneratedAsBracketAlgebra
but I think there is no need to have Bracket
here mean something specific besides being a bilinear operation that is distributive as in 2.
comment:10 in reply to: ↑ 9 ; followup: ↓ 11 Changed 10 months ago by
Replying to heluani:
I think that whatever category of parents
Cs()
where there is a natural notion of finitely generated object, this should be implemented asCs().FinitelyGenerated()
. Here by natural I mean that no mathematician would be confused. A prototypical example isRings()
. Of course one can think of a ring which is finitely generated as an additive magma, but in this case this would be explicit, when we simply sayR
is finitely generated we mean that every element ofR
can be written as a sum of elements of the forma_1 a_2...a_n
fora_i
in a finite set of generators.
Yes, I agree.
Now on the other hand it seems ridiculous to implement axioms
FinitelyGeneratedAs*
for*
meaning an algebra over closely related operads. This does not scale correctly and eventually we will end up with a lot of axioms incategory_with_axiom.py
.
Yes, this (scaling) has also been a concern of mine  and I was secretly hoping that the discussion with Travis on your ticket #30032 would clarify it for me...
So I suggest we implement at least these two generic axioms:
 For objects that are both a (multiplicative) magma and an additive magma and is distributive, implement something like
FinitelyGeneratedAsDistributiveMagmas
which means every element is written as sums of elements of the forma_1...a_n
but now parenthesis are put anywhere.
 For objects as in 1. but in an
R
linear category, that is they areR
modules and they have anR
bilinear operation*
such that the sum is distributive. Then implementFinitelyGeneratedAsDistributiveAlgebras
(perhaps a more generic name is in order and this is unfortunate that algebra means associative in Sage)
... perhaps it's time to introduce the word Lgebra
for notnecessarily associative algebras ...
to mean exactly as above but instead of sums, linear combinations with coefficients in
R
.Then for example
Rings().FinitelyGenerated()
should callFinitelyGeneratedAsDistributiveMagmas
whileLieAlgebras().FinitelyGenerated()
andAlgebras(QQ).FinitelyGenerated()
for example should callFinitelyGeneratedAsDistributiveAlgebras
.
This all sounds great to me.
I can see also a lot of uses for a third option
 Objects as in 2. but with a derivation
D
of the operation*
over the ringR
. In this case we can implementFinitelyGeneratedAsDifferentialAlgebra
(again different name because differential nowadays means with a differential not like Ritt's original definition) Then for example all my three objectsLieConformalAlgebras
,VertexAlgebras
andPoissonVertexAlgebras
would call the same axiomFinitelyGeneratedAsDifferentialAlgebra
instead of having to implement three of them.
When you have a chance, could you elaborate on 3 in simpler terms? This one is going over the top of my head...
comment:11 in reply to: ↑ 10 ; followup: ↓ 12 Changed 10 months ago by
Replying to mkoeppe:
... perhaps it's time to introduce the word
Lgebra
for notnecessarily associative algebras ...
The thing is that in every example that I can think of for 2. it is irrelevant if the algebra is associative or not, on every nonassociative example that I know of (Jordan, Lie, Vertex, Left/Right? Symmetric, Leibniz, etc) the notion of finite generation is independent of the order of parentheses in a_1...a_n
. So for the purposes of this axiom it is the same being a finitely generated associative algebra, or Lie algebra, or Jordan algebra or Left/Right? Symmetric algebra, etc. only matters to have a bilinear operation which distributes over sums.
When you have a chance, could you elaborate on 3 in simpler terms? This one is going over the top of my head...
Sure, here is a different example but shows already a closely related phenomenom: the point is that often time you have an algebra A
which has a bilinear operation (say [,]
for this example) over a ring (say k
). But A
happens to be a module over a k
algebra R
, which is finitely generated over R
but not finitely generated over k
. The prototypical example of this would be A
smooth vector fields on a manifold X
. Then k
is the Real numbers, and R
is the ring of smooth functions over X
. The operation [,]
is k
linear but it is not R
linear. As a Lie algebra over k
, A
is not finitely generated, but as a Lie algebroid over R
it is.
Now the exact example that I meant in 3. Consider a differential polynomial algebra, that is a polynomial algebra k[x, x', x'', ...]
this is a polynomial algebra in infinitely many variables, x
and all of its formal derivatives. So this algebra has a derivation T x^n = x^{n+1}
. This algebra is infinitely generated as an algebra over k
, but it is not a finitely generated algebra over k[T]
since the multiplication is not k[T]
linear. However, every element can be written as linear combination of 1, x
or products of these two and their derivatives. This situation is very closely related to the above one and it happens everywhere from the study of arc spaces, motivic integration etc, to algebraic geometry/representation theory of infinite dimensional algebras.
I apologize if this is getting to "chatty" for a trac ticket.
comment:12 in reply to: ↑ 11 Changed 10 months ago by
Replying to heluani:
I apologize if this is getting to "chatty" for a trac ticket.
To the contrary  this was very helpful. Thanks for taking the time to explain!
comment:13 Changed 10 months ago by
In fact the more I think about this, I convince myself that we only need one axiom instead of 1.3. above: FinitelyGeneratedAsDistributiveMagma
that is called as Cs().FinitelyGenerated()
for every Category Cs()
whose objects are as follows
 There is a ring and its algebra
k > R
.  An object of the category is an
R
module.  The object has a
k
bilinear operation*
that distributes over sums.
Then the category of finitely generated objects is the category of objects such that there exists a finite number of elements a_i
and every element can be written as linear combination with coefficients in k
of elements of the form (r_1.a_1)*(r_2.a_2)*....*(r_n.a_n)
where r_i
is in R
and arbitrary association of the *
operation.
For nonlinear categories like Rings, we would have k = R = ZZ
. For linear categories like Lie/Associative/Jordan/LeftSymmetric?algebras we would have k=R
. For the differential categories as I mentioned above we would have k
and R
arbitrary. The point is that this really encodes every example even from the point of view of implementing this in Sage.
However I think that there may be a difficulty in the current implementation of Rings
cause the category of Rings is not a category over the base ring ZZ
. Anyway I think this example convinces me that 2. and 3. should be one axiom for algebras with a distributive operation that is called on the SubcategoryMethods.FinitelyGenerated()
since this methods can be overriden in subcategories this is not a problem.
For example. LieAlgebras(k).FinitelyGenerated()
would use the k=R
version of the axiom. while LieAlgebroids(R).FinitelyGenerated()
for a k
algebra R
, even though it is a subcategory of LieAlgebras(k)
would override it to call the k, R
version of the axiom. This is purely semantics of course since the Sage implementation of the axiom doesn't care about k
nor R
.
comment:14 Changed 10 months ago by
 Branch set to public/finitely_generated_as_xxx_axioms
 Commit set to 2cf761420fbb107622a8febb4c6a88d1c4493fd9
New commits:
2cf7614  Implement generic FinitelyGenerated axioms

comment:15 Changed 10 months ago by
I thought I'll add a little test to show some of the difficulty that may arise if implementing generic FinitelyGenerated
methods. Here's the commit message from that branch
This commit adds three axioms
FinitelyGeneratedAsDistributiveMagma
. An objectC
with two magmatic operations*
and+
, such that*
distributes over+
is said to be finitely generated if there exists a finite subsetA \subset C
such that every element can be written as sum of elements of the forma_1*...*a_n
with any parenthesis assignment anda_i \in A
for everyi
FinitelyGeneratedAsAlgebra
. An object asC
above with the which in addition is ak
module and the operation*
isk
bilinear is finitely generated if every element can be written as a linear combination of elements as in 1.FinitelyGeneratedAsLieAlgebroid
. An object asC
above, with an additional structure of being anR
module for ak
algebraR
.C
is called finitely generated if every element can be written as ak
linear combination of elements of the form(r_1 a_1)*....*(r_n a_n)
witha_i \in A
andr_i \in R
for everyi
and any parenthesis assignment.
It adds a bare class FinitelyGeneratedRings
and implements
Rings().FinitelyGenerated()
and LieAlgebras().FinitelyGenerated()
just to show the difficulties that we would encounter with this generic
approach: for a Lie algebra, gens
is not what is meant by "generators"
usually, but what is meant by a "basis". Of course finite gens
implies
FinitelyGeneratedAsAlgebra
but not conversely.
The same abuse is currently used in LieConformalAlgebras
where gens
means a set of generators as an R
module (notation as in 3. above). So
again finite gens
implies FinitelyGeneratedAsAlgebroid
but not
conversely.
comment:16 Changed 10 months ago by
 Milestone changed from sage9.2 to sage9.3
comment:17 Changed 4 months ago by
 Milestone changed from sage9.3 to sage9.4
Setting new milestone based on a cursory review of ticket status, priority, and last modification date.
I've implemented three more with
FinitelyGeneratedAsLieConformalAlgebra
,FinitelyGeneratedAsVertexAlgebra
andFinitelyGeneratedAsPoissonVertexAlgebra
I think it's only a matter of time until people (like me) are drawn to Sage and start implementing more.For
Modules(QQ)
this was probably left intentionally like this. I can see a few reasons for this, since for modules over ak
algebraR
,FiniteDimensional
means typically finite dimensional overk
, it could be very confusing/tricky to have amodules.SubcategoryMethods.FinitelyGenerated
.