FormalPolyhedraModule - (so far finitely generated) free modules

[mkoeppe]

Add a class FormalPolyhedraModule for formal modules generated by polyhedra, graded by dimension, and a category PolyhedraModules.

So far everything is finitely generated. This will be changed in follow-up tickets.

CC: @tscrim @braunmath

Component: geometry

Author: Matthias Koeppe

Branch/Commit: 463dea2

Reviewer: Travis Scrimshaw

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

[mkoeppe]

Branch: u/mkoeppe/formalpolyhedramodule____so_far_finitely_generated__free_modules

[mkoeppe]

Commit: b9d939c

[mkoeppe]

Author: Matthias Koeppe

[mkoeppe]

New commits:

b9d939c

sage.geometry.polyhedron.modules.formal_polyhedra_module: New

[sagetrac-git]

Changed commit from b9d939c to 8721d98

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

8721d98

Add __init__.py and imports

[mkoeppe]

comment:4

The results of retract print using a prefix "B". Do I need to override the submodule method?

[tscrim]

comment:5

This is the default prefix for a submodule, so if you want a different prefix, you will need to override it with something like

def submodule(self, gens, check=True, already_echelonized=False,
              unitriangular=False, category=None):
    if not already_echelonized:
        gens = self.echelon_form(gens, unitriangular)
    from sage.modules.with_basis.subquotient import SubmoduleWithBasis
        return SubmoduleWithBasis(gens, ambient=self, prefix='M',
                                  unitriangular=unitriangular,
                                  category=category)

However, you can set/change this dynamically at any point with:

sage: M_lower.print_options(prefix='V')
sage: y
V[0]

Although there probably should be an option added to the submodule to pass along such information to the submodule's constructor...

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

fd5bc34

sage.categories.polyhedra_modules: New

[sagetrac-git]

Changed commit from 8721d98 to fd5bc34

[mkoeppe]

comment:7

Is the idea of the prefix for the submodule elements to refer to the ambient module, or to distinguish from the ambient module?

[tscrim]

comment:8

I am not quite sure I understand your question. All CFMs have a prefix parameter that can be set by the user to help them distinguish between the different *modules they are working with. This is used extensively in Sage (e.g., symmetric functions).

[mkoeppe]

comment:9

I guess I need to ask a more basic question first. In the example:

   sage: M.basis()
   Finite family {conv([0], [1]): [conv([0], [1])], {[1]}: [{[1]}], conv([1], [2]): 
   [conv([1], [2])]}
   sage: M_lower.basis()
   Finite family {0: B[0]}

How come these two bases (of the ambient module and of the submodule) are indexed in very different ways?

[tscrim]

comment:10

A submodule of dimension d just uses the indexing set 0,...,d-1 because any generic submodule would not necessarily have any particular way to relate its basis with that of the ambient module. Moreover, it needs some indexing set for the basis, so it just chooses the simplest and most generic one. One possible way would be to use the leading support of each of the echeleonized basis elements, but that still feels fairly artificial/arbitrary to me.

[mkoeppe]

comment:11

OK, thanks a lot for the explanation. I think I will revisit this cosmetic issue later.