-
-
Notifications
You must be signed in to change notification settings - Fork 453
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FormalPolyhedraModule - (so far finitely generated) free modules #29801
Comments
Commit: |
Author: Matthias Koeppe |
New commits:
|
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:4
The results of |
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:
Although there probably should be an option added to the |
Branch pushed to git repo; I updated commit sha1. New commits:
|
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? |
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). |
comment:9
I guess I need to ask a more basic question first. In the example:
How come these two bases (of the ambient module and of the submodule) are indexed in very different ways? |
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. |
comment:11
OK, thanks a lot for the explanation. I think I will revisit this cosmetic issue later. |
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
|
Branch pushed to git repo; I updated commit sha1. New commits:
|
Branch pushed to git repo; I updated commit sha1. New commits:
|
This comment has been minimized.
This comment has been minimized.
comment:17
At this point, I don't see the need for having a category If you do keep the category, Your
Note the alignment (you have an additional 1 space indentation) and the double
|
comment:18
Replying to @tscrim:
It is indeed for future use, when I introduce the space generated by indicator functions of polyhedra, which is the quotient by all inclusion-exclusion relations. That space is no longer graded, but only filtered by dimension. |
comment:19
But I'll follow your advice and make it just a method of the class for now. |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:21
Replying to @tscrim:
Thanks, fixed. I really wish we had a linter for the docstrings that we could run locally instead of wasting reviewers' time with these formatting details and/or waiting for the patchbot... |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:23
Sorry, that wasn't meant to be a suggestion to remove it; it was purely a question as I don't know what your long term structural plans are. Although I do think purely local to this ticket it is better. Your sage: from sage.geometry.polyhedron.modules.formal_polyhedra_module import FormalPolyhedraModule
sage: def closed_interval(a,b): return Polyhedron(vertices=[[a], [b]])
sage: I01 = closed_interval(0, 1); I01.rename("conv([0], [1])")
sage: I11 = closed_interval(1, 1); I11.rename("{[1]}")
sage: I12 = closed_interval(1, 2); I12.rename("conv([1], [2])")
sage: I02 = closed_interval(0, 2); I02.rename("conv([0], [2])")
sage: M = FormalPolyhedraModule(QQ, 1, basis=[I01, I11, I12, I02])
sage: TestSuite(M).run() To help avoid some confusion in Indeed, such a linter would be nice. |
comment:25
Done. |
comment:27
Thank you. |
Reviewer: Travis Scrimshaw |
comment:28
Thanks! |
Changed branch from u/mkoeppe/formalpolyhedramodule____so_far_finitely_generated__free_modules to |
Add a class
FormalPolyhedraModule
for formal modules generated by polyhedra, graded by dimension, and a categoryPolyhedraModules
.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
The text was updated successfully, but these errors were encountered: