Sage: Ticket #21255: Categories for Cones
https://trac.sagemath.org/ticket/21255
<p>
Right now a <code>Cone</code> is not a parent, and it does not have a specific category.
</p>
<pre class="wiki">sage: C = Cone([[1,0], [1,5]])
sage: C.category()
Category of objects
</pre><p>
I am wondering whether suitable categories, such as <code>SemiModules</code> (here, using the monoid of nonnegative integers), <code>Cones</code> (nonnegative reals), ... should be set up.
This category framework should then be general enough to represent other (non-polyhedral) cones, such as the cone of convex functions of a real variable; the cone of semidefinite matrices; etc.
</p>
<p>
Also, there should be a method to create the affine semigroup of the integer points in a cone (its generators are computed by the method <code>semigroup_generators</code>) as a monoid.
</p>
en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/21255
Trac 1.1.6tscrimTue, 16 Aug 2016 00:17:28 GMT
https://trac.sagemath.org/ticket/21255#comment:1
https://trac.sagemath.org/ticket/21255#comment:1
<p>
You can do more than 1 category, i.e. create a subcategory for polyhedral cones. However, right now we unfortunately have (very) limited support for categories with just objects (those that don't fit into the Parent-Element setup) (unless I am forgetting something, Nicolas?). So you might run into this technical limitation if you wanted to pull generic object code into the category, unless you are thinking of making cones a parent with an element class? Nevertheless, there could likely be code for morphisms and functors you could be able to apply.
</p>
TicketmkoeppeTue, 16 Aug 2016 00:40:51 GMT
https://trac.sagemath.org/ticket/21255#comment:2
https://trac.sagemath.org/ticket/21255#comment:2
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/21255#comment:1" title="Comment 1">tscrim</a>:
</p>
<blockquote class="citation">
<p>
[...] unless you are thinking of making cones a parent with an element class?
</p>
</blockquote>
<p>
That's part of what I am trying to figure out. Likewise, for polyhedra and the points contained in them - there is also no parent/element relationship at the moment.
</p>
TicketnovoseltTue, 16 Aug 2016 13:55:04 GMT
https://trac.sagemath.org/ticket/21255#comment:3
https://trac.sagemath.org/ticket/21255#comment:3
<p>
But points of a cone/polyhedron are elements of a vector space parent. Do you want to wrap them up for the sake of points knowing that they belong to a certain cone? With different instances for the same point belonging to different cones? The setup for toric cones etc. was that generating points are shared between related structures, as in they are the same objects to decrease memory consumption and increase speed of construction.
</p>
TicketmkoeppeWed, 17 Aug 2016 23:55:48 GMT
https://trac.sagemath.org/ticket/21255#comment:4
https://trac.sagemath.org/ticket/21255#comment:4
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/21255#comment:3" title="Comment 3">novoselt</a>:
</p>
<blockquote class="citation">
<p>
But points of a cone/polyhedron are elements of a vector space parent. Do you want to wrap them up for the sake of points knowing that they belong to a certain cone? With different instances for the same point belonging to different cones? The setup for toric cones etc. was that generating points are shared between related structures, as in they are the same objects to decrease memory consumption and increase speed of construction.
</p>
</blockquote>
<p>
Thanks for sharing this perspective and background. However it seems that it is a goal in Sage that "every set should be a parent".
Perhaps <a class="ext-link" href="http://doc.sagemath.org/html/en/reference/categories/sage/categories/sets_cat.html#facade-sets"><span class="icon"></span>Facade sets</a> can help to reconcile this goal and the goal of efficiency?
</p>
TicketnovoseltThu, 18 Aug 2016 03:25:48 GMT
https://trac.sagemath.org/ticket/21255#comment:5
https://trac.sagemath.org/ticket/21255#comment:5
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/21255#comment:4" title="Comment 4">mkoeppe</a>:
</p>
<blockquote class="citation">
<p>
Thanks for sharing this perspective and background. However it seems that it is a goal in Sage that "every set should be a parent".
</p>
</blockquote>
<p>
Can you please clarify "seems"? Do we have some written policy/recommendation for this? Does it cover subsets of bigger sets? I.e. if I have a bunch of subsets of some set S, should elements of each of these subsets have different parents rather than S? Seems quite odd to me. What about parents for operations? Should adding two points belonging to two cones result in constructing the Minkowski sum cone where the result is guaranteed to live???
</p>
TicketmkoeppeThu, 18 Aug 2016 06:18:53 GMT
https://trac.sagemath.org/ticket/21255#comment:6
https://trac.sagemath.org/ticket/21255#comment:6
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/21255#comment:5" title="Comment 5">novoselt</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/21255#comment:4" title="Comment 4">mkoeppe</a>:
</p>
<blockquote class="citation">
<p>
Thanks for sharing this perspective and background. However it seems that it is a goal in Sage that "every set should be a parent".
</p>
</blockquote>
<p>
Can you please clarify "seems"? Do we have some written policy/recommendation for this?
</p>
</blockquote>
<p>
I'm afraid the project is a bit short on policies. It's what I gathered from reading <a class="ext-link" href="http://doc.sagemath.org/html/en/reference/categories/sage/categories/primer.html"><span class="icon"></span>http://doc.sagemath.org/html/en/reference/categories/sage/categories/primer.html</a>, <a class="ext-link" href="https://trac.sagemath.org/wiki/CategoriesRoadMap"><span class="icon"></span>https://trac.sagemath.org/wiki/CategoriesRoadMap</a> etc. and looking at various examples such as posets.
</p>
<p>
Hoping that people familiar with the category framework can help to clarify.
</p>
<blockquote class="citation">
<p>
Does it cover subsets of bigger sets? I.e. if I have a bunch of subsets of some set S, should elements of each of these subsets have different parents rather than S? Seems quite odd to me.
</p>
</blockquote>
<p>
It's already the case as soon as the subsets have enough (algebraic) structure. Example, for point lattices:
</p>
<pre class="wiki">sage: L1 = (QQ^2).span([[1, 6], [1,0]], ZZ)
sage: L2 = (QQ^2).span([[1, 3], [1,0]], ZZ)
sage: L1.0
(1, 0)
sage: L2.0
(1, 0)
sage: L1.0 == L2.0
True
sage: L1.0.parent()
Free module of degree 2 and rank 2 over Integer Ring
Echelon basis matrix:
[1 0]
[0 6]
sage: L2.0.parent()
Free module of degree 2 and rank 2 over Integer Ring
Echelon basis matrix:
[1 0]
[0 3]
</pre><p>
I guess in the end the question is: Do cones have enough structure to warrant similar behavior? The category- and axiom-based inheritance of methods, including _test_* methods, seems quite attractive to me, and it would be nice if cones could benefit from this infrastructure.
</p>
<blockquote class="citation">
<p>
What about parents for operations? Should adding two points belonging to two cones result in constructing the Minkowski sum cone where the result is guaranteed to live???
</p>
</blockquote>
<p>
It sounds a bit excessive, but that matches the sound of the word "pushout".
</p>
TickettscrimFri, 19 Aug 2016 02:12:46 GMT
https://trac.sagemath.org/ticket/21255#comment:7
https://trac.sagemath.org/ticket/21255#comment:7
<p>
If you want to consider a cone is considered as a set of objects (i.e., an object in a concrete category), then it should be a <code>Parent</code> and the elements should be a subclass of <code>Element</code>. If you want to consider them in some objects in a non-concrete category, then I think they should just be a <code>CategoryObject</code> (where we would need to add support for <code>ObjectMethods</code>, but you can work around this for now with an ABC). Be warned, we have yet to really include non-concrete categories, so you are wondering into the wilderness here.
</p>
<p>
A facade parent <code>P</code> is for when the elements of <code>P</code> would more naturally belong to another parent, but you want to construct them through <code>P</code>.
</p>
<p>
However, it seems the idea is to consider cones as a vector space but over a semiring (more explicitly, an additive monoid with a distributive multiplicative structure). Perhaps a more simple question, is every module over a (commutative?) ring/field a cone?
</p>
<p>
The pushout construction of Sage should work well if you do want to have compatible arithmetic and coercion.
</p>
TicketnovoseltFri, 19 Aug 2016 02:42:49 GMT
https://trac.sagemath.org/ticket/21255#comment:8
https://trac.sagemath.org/ticket/21255#comment:8
<p>
I am all for extra features and functionality, especially implemented by others, as long as it does not severely harm "usual" usage. Constructing Minkowski sum of cones when adding a couple of vectors does not sound reasonable to me as it is a very expensive operation for non-trivial cones.
</p>
TicketmkoeppeFri, 19 Aug 2016 04:51:09 GMT
https://trac.sagemath.org/ticket/21255#comment:9
https://trac.sagemath.org/ticket/21255#comment:9
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/21255#comment:7" title="Comment 7">tscrim</a>:
</p>
<blockquote class="citation">
<p>
However, it seems the idea is to consider cones as a vector space but over a semiring (more explicitly, an additive monoid with a distributive multiplicative structure). Perhaps a more simple question, is every module over a (commutative?) ring/field a cone?
</p>
</blockquote>
<p>
One would take the nonnegative elements of an ordered field, not an arbitrary commutative ring. They form a semiring. The (semi)modules over this semiring would be a cone.
</p>
<p>
A non-example, the nonnegative integer vectors of <code>RR^2</code> would not form a cone because they are merely a semimodule over Z_+ , not an ordered field (equivalently, an additive monoid).
</p>
TicketmkoeppeTue, 21 Jul 2020 20:24:27 GMTmilestone set
https://trac.sagemath.org/ticket/21255#comment:10
https://trac.sagemath.org/ticket/21255#comment:10
<ul>
<li><strong>milestone</strong>
set to <em>sage-9.2</em>
</li>
</ul>
TicketmkoeppeThu, 13 Aug 2020 17:11:30 GMTmilestone changed
https://trac.sagemath.org/ticket/21255#comment:11
https://trac.sagemath.org/ticket/21255#comment:11
<ul>
<li><strong>milestone</strong>
changed from <em>sage-9.2</em> to <em>sage-9.3</em>
</li>
</ul>
TicketmkoeppeSat, 13 Feb 2021 20:51:01 GMTmilestone changed
https://trac.sagemath.org/ticket/21255#comment:12
https://trac.sagemath.org/ticket/21255#comment:12
<ul>
<li><strong>milestone</strong>
changed from <em>sage-9.3</em> to <em>sage-9.4</em>
</li>
</ul>
<p>
Setting new milestone based on a cursory review of ticket status, priority, and last modification date.
</p>
Ticket