Axioms FinitelyGenerated, FinitelyGeneratedAs....

[mkoeppe]

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'

CC: @tscrim @nthiery @heluani

Component: categories

Branch/Commit: public/finitely_generated_as_xxx_axioms @ 2cf7614

Issue created by migration from https://trac.sagemath.org/ticket/30233

[heluani]

comment:1

I've implemented three more with FinitelyGeneratedAsLieConformalAlgebra, FinitelyGeneratedAsVertexAlgebra and FinitelyGeneratedAsPoissonVertexAlgebra 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 a k algebra R, FiniteDimensional means typically finite dimensional over k, it could be very confusing/tricky to have a modules.SubcategoryMethods.FinitelyGenerated.

[mkoeppe]

comment:2

Replying to @heluani:

I've implemented three more with FinitelyGeneratedAsLieConformalAlgebra, FinitelyGeneratedAsVertexAlgebra and FinitelyGeneratedAsPoissonVertexAlgebra 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 a k algebra R, FiniteDimensional means typically finite dimensional over k, it could be very confusing/tricky to have a modules.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.

[nthiery]

comment:3

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 user-level 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/R-trivial or note, etc.

Maybe it should just not exist.

[nthiery]

comment:4

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.

[mkoeppe]

comment:5

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 returning Modules(R).FiniteDimensional().

Thanks! I'll try this.

(note: Modules(R).WithBasis().FinitelyGenerated() won't be Modules(R).FiniteDimensional() but Modules(R).WithBasis().FiniteDimensional()).

Right, that's what I meant.

[mkoeppe]

comment:6

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?

[mkoeppe]

comment:7

Replying to @heluani:

for modules over a k algebra R, FiniteDimensional means typically finite dimensional over k, it could be very confusing/tricky to have a modules.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

[heluani]

comment:8

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.

[heluani]

comment:9

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:

1. 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 form a_1...a_n but now parenthesis are put anywhere.

2. For objects as in 1. but in an R-linear category, that is they are R-modules and they have an R-bilinear operation * such that the sum is distributive. Then implement FinitelyGeneratedAsDistributiveAlgebras (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 in R.

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

3. Objects as in 2. but with a derivation D of the operation * over the ring R. In this case we can implement FinitelyGeneratedAsDifferentialAlgebra (again different name because differential nowadays means with a differential not like Ritt's original definition) Then for example all my three objects LieConformalAlgebras, VertexAlgebras and PoissonVertexAlgebras would call the same axiom FinitelyGeneratedAsDifferentialAlgebra 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.

[mkoeppe]

comment:10

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 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.

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 in category_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:

1. 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 form a_1...a_n but now parenthesis are put anywhere.

2. For objects as in 1. but in an R-linear category, that is they are R-modules and they have an R-bilinear operation * such that the sum is distributive. Then implement FinitelyGeneratedAsDistributiveAlgebras (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 not-necessarily associative algebras ...

to mean exactly as above but instead of sums, linear combinations with coefficients in R.

Then for example Rings().FinitelyGenerated() should call FinitelyGeneratedAsDistributiveMagmas while LieAlgebras().FinitelyGenerated() and Algebras(QQ).FinitelyGenerated() for example should call FinitelyGeneratedAsDistributiveAlgebras.

This all sounds great to me.

I can see also a lot of uses for a third option

3. Objects as in 2. but with a derivation D of the operation * over the ring R. In this case we can implement FinitelyGeneratedAsDifferentialAlgebra (again different name because differential nowadays means with a differential not like Ritt's original definition) Then for example all my three objects LieConformalAlgebras, VertexAlgebras and PoissonVertexAlgebras would call the same axiom FinitelyGeneratedAsDifferentialAlgebra 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...

[heluani]

comment:11

Replying to @mkoeppe:

... perhaps it's time to introduce the word Lgebra for not-necessarily 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 non-associative 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.

[mkoeppe]

comment:12

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!

[heluani]

comment:13

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

a. There is a ring and its algebra k -> R. b. An object of the category is an R module. c. 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 non-linear 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.

[heluani]

New commits:

2cf7614

Implement generic FinitelyGenerated axioms

[heluani]

Branch: public/finitely_generated_as_xxx_axioms

[heluani]

Commit: 2cf7614

[heluani]

comment:15

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

1. FinitelyGeneratedAsDistributiveMagma. An object C with two magmatic operations * and +, such that * distributes over + is said to be finitely generated if there exists a finite subset A \subset C such that every element can be written as sum of elements of the form a_1*...*a_n with any parenthesis assignment and a_i \in A for every i
2. FinitelyGeneratedAsAlgebra. An object as C above with the which in addition is a k-module and the operation * is k-bilinear is finitely generated if every element can be written as a linear combination of elements as in 1.
3. FinitelyGeneratedAsLieAlgebroid. An object as C above, with an additional structure of being an R-module for a k-algebra R. C is called finitely generated if every element can be written as a k-linear combination of elements of the form (r_1 a_1)*....*(r_n a_n) with a_i \in A and r_i \in R for every i 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.

[mkoeppe]

comment:17

Setting new milestone based on a cursory review of ticket status, priority, and last modification date.