Sage: Ticket #27973: Implement wedge over a face of Polyhedron
https://trac.sagemath.org/ticket/27973
<p>
From <a class="ext-link" href="https://www.csun.edu/~ctoth/Handbook/chap15.pdf"><span class="icon"></span>https://www.csun.edu/~ctoth/Handbook/chap15.pdf</a>:
</p>
<p>
The wedge over a facet <code>F</code> of a polytope <code>P</code> is defined as the product:
</p>
<p>
<code>P \times \mathbb{R}\cap \{a^\top x +|x_{d+1} \leq b|\}</code>
</p>
<p>
where <code>F</code> is a facet defined by <code>a^\top x leq b</code>.
</p>
<p>
It has dimension <code>d+1</code>, <code>m+1</code> facets, and <code>2n-n_F</code> vertices, if <code>F</code> has <code>n_F</code> vertices. More generally, the wedge construction can be performed (defined by the same formula) for a face <code>F</code>.
</p>
en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/27973
Trac 1.1.6gh-kliemWed, 12 Jun 2019 08:51:43 GMTdescription changed
https://trac.sagemath.org/ticket/27973#comment:1
https://trac.sagemath.org/ticket/27973#comment:1
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/27973?action=diff&version=1">diff</a>)
</li>
</ul>
TicketembrayFri, 14 Jun 2019 14:55:02 GMTmilestone deleted
https://trac.sagemath.org/ticket/27973#comment:2
https://trac.sagemath.org/ticket/27973#comment:2
<ul>
<li><strong>milestone</strong>
<em>sage-8.8</em> deleted
</li>
</ul>
<p>
As the Sage-8.8 release milestone is pending, we should delete the sage-8.8 milestone for tickets that are not actively being worked on or that still require significant work to move forward. If you feel that this ticket should be included in the next Sage release at the soonest please set its milestone to the next release milestone (sage-8.9).
</p>
TicketjipilabMon, 22 Jul 2019 16:40:20 GMTkeywords changed
https://trac.sagemath.org/ticket/27973#comment:3
https://trac.sagemath.org/ticket/27973#comment:3
<ul>
<li><strong>keywords</strong>
<em>days100</em> added; <em></em> removed
</li>
</ul>
Ticketgh-LaisRastTue, 23 Jul 2019 13:49:03 GMTkeywords, status changed; commit, branch, author set
https://trac.sagemath.org/ticket/27973#comment:4
https://trac.sagemath.org/ticket/27973#comment:4
<ul>
<li><strong>keywords</strong>
<em>wedge</em> <em>facet</em> added
</li>
<li><strong>commit</strong>
set to <em>45bd3123afcafe3ef142e19bbb04f0d6ebda849e</em>
</li>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_info</em>
</li>
<li><strong>branch</strong>
set to <em>public/27973</em>
</li>
<li><strong>author</strong>
set to <em>Laith Rastanawi</em>
</li>
</ul>
<p>
New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=d0be5c632aec8c8c8164b73dcdbf66a4508a880b"><span class="icon"></span>d0be5c6</a></td><td><code>add wedge method in Polyhedron class in base.py</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=45bd3123afcafe3ef142e19bbb04f0d6ebda849e"><span class="icon"></span>45bd312</a></td><td><code>NotImplementedError -> ValueError</code>
</td></tr></table>
Ticketgh-LaisRastTue, 23 Jul 2019 13:51:16 GMTstatus changed
https://trac.sagemath.org/ticket/27973#comment:5
https://trac.sagemath.org/ticket/27973#comment:5
<ul>
<li><strong>status</strong>
changed from <em>needs_info</em> to <em>needs_review</em>
</li>
</ul>
TicketjipilabTue, 23 Jul 2019 14:23:47 GMT
https://trac.sagemath.org/ticket/27973#comment:6
https://trac.sagemath.org/ticket/27973#comment:6
<p>
Hi,
</p>
<ul><li>In the docstring, it usually starts with 1 sentence, and empty line and then further information about the method.
</li></ul><ul><li>I would say that the width is a "indication of how wide the wedge is taken around the face". Said the current way, it makes it confusing about other potential notions around polytopes (lattice polytopes have widths...) So I would say: "indication of how wide the resulted wedge should be".
</li></ul><ul><li>The doctests are not using the function as a method.
</li></ul><ul><li>Replace the backtick by single quotes in the error messages.
</li></ul><ul><li><code>L = Polyhedron(rays=[[1],[-1]])</code> could be <code>Polyhedron(lines=[[1]])</code>
</li></ul><ul><li>I would write <code>F_Hrep = list(F_Hrep)</code> after the for loop and replace in the creation of the polytope.
</li></ul><ul><li>It would be good to test and show in examples combinatorial isomorphism type with a known polytope which is a wedge. For example the prism over a triangle is a wedge over a triangle. And the duals to cyclic 3-polytopes are wedges.
</li></ul>
TicketjipilabTue, 23 Jul 2019 14:23:53 GMTstatus changed
https://trac.sagemath.org/ticket/27973#comment:7
https://trac.sagemath.org/ticket/27973#comment:7
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
TicketgitTue, 23 Jul 2019 15:07:24 GMTcommit changed
https://trac.sagemath.org/ticket/27973#comment:8
https://trac.sagemath.org/ticket/27973#comment:8
<ul>
<li><strong>commit</strong>
changed from <em>45bd3123afcafe3ef142e19bbb04f0d6ebda849e</em> to <em>049e27d49147ebf269a0d3267ae0dd32c1637e42</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=049e27d49147ebf269a0d3267ae0dd32c1637e42"><span class="icon"></span>049e27d</a></td><td><code>more examples and fix docstring</code>
</td></tr></table>
Ticketgh-LaisRastTue, 23 Jul 2019 15:09:12 GMTstatus changed
https://trac.sagemath.org/ticket/27973#comment:9
https://trac.sagemath.org/ticket/27973#comment:9
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
</ul>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/27973#comment:7" title="Comment 7">jipilab</a>:
</p>
<p>
Thanks. Done.
</p>
TicketjipilabTue, 23 Jul 2019 20:29:42 GMT
https://trac.sagemath.org/ticket/27973#comment:10
https://trac.sagemath.org/ticket/27973#comment:10
<p>
Seems like there are tab character in reference/index.rst There seems to be many errors in the bot too...
</p>
TicketgitWed, 24 Jul 2019 08:09:36 GMTcommit changed
https://trac.sagemath.org/ticket/27973#comment:11
https://trac.sagemath.org/ticket/27973#comment:11
<ul>
<li><strong>commit</strong>
changed from <em>049e27d49147ebf269a0d3267ae0dd32c1637e42</em> to <em>193e06bd91b8cd16d8ec796fcae0ac91ee8b592a</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=193e06bd91b8cd16d8ec796fcae0ac91ee8b592a"><span class="icon"></span>193e06b</a></td><td><code>tabs to spaces</code>
</td></tr></table>
Ticketgh-kliemWed, 24 Jul 2019 08:46:35 GMT
https://trac.sagemath.org/ticket/27973#comment:12
https://trac.sagemath.org/ticket/27973#comment:12
<p>
The description of the ticket is still only about facets.
</p>
Ticketgh-kliemWed, 24 Jul 2019 08:54:27 GMTstatus changed
https://trac.sagemath.org/ticket/27973#comment:13
https://trac.sagemath.org/ticket/27973#comment:13
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
Please preserve the backend and base ring as in <a class="closed ticket" href="https://trac.sagemath.org/ticket/27926" title="enhancement: Preserve backend for polytopal constructions (closed: fixed)">#27926</a>.
</p>
Ticketgh-kliemWed, 24 Jul 2019 09:31:28 GMT
https://trac.sagemath.org/ticket/27973#comment:14
https://trac.sagemath.org/ticket/27973#comment:14
<p>
Actually, I think the backend might be preserved. (product and intersection might behave this way).
</p>
<p>
Can you please check. Maybe add a doctest.
</p>
<p>
However, in the intermediate steps you don't preserve the backend. This might cause issues with algebraic polyhedra.
</p>
TicketjipilabWed, 24 Jul 2019 10:28:39 GMT
https://trac.sagemath.org/ticket/27973#comment:15
https://trac.sagemath.org/ticket/27973#comment:15
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/27973#comment:12" title="Comment 12">gh-kliem</a>:
</p>
<blockquote class="citation">
<p>
The description of the ticket is still only about facets.
</p>
</blockquote>
<p>
Nope. See last sentence of the description.
</p>
Ticketgh-LaisRastWed, 24 Jul 2019 13:32:07 GMT
https://trac.sagemath.org/ticket/27973#comment:16
https://trac.sagemath.org/ticket/27973#comment:16
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/27973#comment:14" title="Comment 14">gh-kliem</a>:
</p>
<blockquote class="citation">
<p>
Actually, I think the backend might be preserved. (product and intersection might behave this way).
</p>
<p>
Can you please check. Maybe add a doctest.
</p>
<p>
However, in the intermediate steps you don't preserve the backend. This might cause issues with algebraic polyhedra.
</p>
</blockquote>
<p>
The backend and the basering are preserved as long as the value of <code>width</code> belongs to the basering of <code>self</code>. This is the case when <code>width</code> takes the default value. Otherwise, we have the following behavior
</p>
<pre class="wiki">sage: P = polytopes.cyclic_polytope(3,7); P
A 3-dimensional polyhedron in QQ^3 defined as the convex hull of 7 vertices
sage: P.backend()
'ppl'
sage: P.wedge(P.faces(2)[0]).backend()
'ppl'
sage: P.wedge(P.faces(2)[0]).base_ring()
Rational Field
sage: P.wedge(P.faces(2)[0], width=RDF(1)).backend()
cdd
sage: P.wedge(P.faces(2)[0], width=RDF(1)).base_ring()
Real Double Field
</pre><p>
which I think is an acceptable behavior.
</p>
TicketgitWed, 24 Jul 2019 13:46:40 GMTcommit changed
https://trac.sagemath.org/ticket/27973#comment:17
https://trac.sagemath.org/ticket/27973#comment:17
<ul>
<li><strong>commit</strong>
changed from <em>193e06bd91b8cd16d8ec796fcae0ac91ee8b592a</em> to <em>417bfac337f17e93494d8f31b9031f9311cee423</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=417bfac337f17e93494d8f31b9031f9311cee423"><span class="icon"></span>417bfac</a></td><td><code>add tests to check backend and basering</code>
</td></tr></table>
Ticketgh-kliemWed, 24 Jul 2019 14:21:06 GMT
https://trac.sagemath.org/ticket/27973#comment:18
https://trac.sagemath.org/ticket/27973#comment:18
<p>
The examples you gave are not meaningful. ppl and cdd are the standard backends for the given ring.
</p>
<p>
What about normaliz with base ring ZZ and width 5/2 (even worse 4/2)? (I suspect backend will not be preserved).
</p>
<p>
What about the examples of <a class="closed ticket" href="https://trac.sagemath.org/ticket/25097" title="enhancement: Algebraic polyhedra with Normaliz / e-antic (closed: fixed)">#25097</a>. Do they work?
</p>
<p>
(Sorry, still can't test it myself).
</p>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/27973#comment:16" title="Comment 16">gh-LaisRast</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/27973#comment:14" title="Comment 14">gh-kliem</a>:
</p>
<blockquote class="citation">
<p>
Actually, I think the backend might be preserved. (product and intersection might behave this way).
</p>
<p>
Can you please check. Maybe add a doctest.
</p>
<p>
However, in the intermediate steps you don't preserve the backend. This might cause issues with algebraic polyhedra.
</p>
</blockquote>
<p>
The backend and the basering are preserved as long as the value of <code>width</code> belongs to the basering of <code>self</code>. This is the case when <code>width</code> takes the default value. Otherwise, we have the following behavior
</p>
<pre class="wiki">sage: P = polytopes.cyclic_polytope(3,7); P
A 3-dimensional polyhedron in QQ^3 defined as the convex hull of 7 vertices
sage: P.backend()
'ppl'
sage: P.wedge(P.faces(2)[0]).backend()
'ppl'
sage: P.wedge(P.faces(2)[0]).base_ring()
Rational Field
sage: P.wedge(P.faces(2)[0], width=RDF(1)).backend()
cdd
sage: P.wedge(P.faces(2)[0], width=RDF(1)).base_ring()
Real Double Field
</pre><p>
which I think is an acceptable behavior.
</p>
</blockquote>
Ticketgh-LaisRastWed, 24 Jul 2019 15:28:21 GMT
https://trac.sagemath.org/ticket/27973#comment:19
https://trac.sagemath.org/ticket/27973#comment:19
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/27973#comment:18" title="Comment 18">gh-kliem</a>:
</p>
<blockquote class="citation">
<p>
What about normaliz with base ring ZZ and width 5/2 (even worse 4/2)? (I suspect backend will not be preserved).
</p>
<p>
What about the examples of <a class="closed ticket" href="https://trac.sagemath.org/ticket/25097" title="enhancement: Algebraic polyhedra with Normaliz / e-antic (closed: fixed)">#25097</a>. Do they work?
</p>
<p>
(Sorry, still can't test it myself).
</p>
</blockquote>
<p>
The polyhedron <code>H</code> is the responsible for changing the base ring and the backend. The following should fix the problem (up to change of base ring form ZZ to QQ, see <code>W2</code> below):
</p>
<div class="wiki-code"><div class="code"><pre><span class="gd">- def wedge(self, face, width=1):
</span><span class="gi">+ def wedge(self, face, width=None):
</span> r"""
Return the wedge over a ``face`` of the polytope ``self``.
<span class="gu">@@ -4205,6 +4205,10 @@ class Polyhedron_base(Element):
</span> sage: P.wedge(P.faces(2)[0], width=RDF(1)).base_ring()
Real Double Field
"""
<span class="gi">+ if width is None:
+ width = ZZ.one()
+
</span> if not self.is_compact():
raise ValueError("polyhedron 'self' must be a polytope")
<span class="gu">@@ -4223,7 +4227,11 @@ class Polyhedron_base(Element):
</span>
L = Polyhedron(lines=[[1]])
Q = self.product(L)
<span class="gd">- H = Polyhedron(ieqs=[F_Hrep + [width], F_Hrep + [-width]])
</span><span class="gi">+
+ parent = self.parent().base_extend(width, ambient_dim=self.ambient_dim()+1)
+ ieqs = [F_Hrep + [width], F_Hrep + [-width]]
+ H = parent.element_class(parent, None, [ieqs, None])
</span> return Q.intersection(H)
</pre></div></div><p>
Some examples:
</p>
<pre class="wiki">sage: P = polytopes.cyclic_polytope(3,7, base_ring=ZZ, backend='normaliz')
sage: W1 = P.wedge(P.faces(2)[0]); W1.base_ring(); W1.backend()
Integer Ring
'normaliz'
sage: W2 = P.wedge(P.faces(2)[0], width=5/2); W2.base_ring(); W2.backend()
Rational Field
'normaliz'
sage: W2 = P.wedge(P.faces(2)[0], width=4/2); W2.base_ring(); W2.backend()
Rational Field
'normaliz'
sage: W2.vertices()
(A vertex at (0, 0, 0, 0),
A vertex at (1, 1, 1, 0),
A vertex at (2, 4, 8, 0),
A vertex at (3, 9, 27, -3),
A vertex at (3, 9, 27, 3),
A vertex at (4, 16, 64, -12),
A vertex at (4, 16, 64, 12),
A vertex at (5, 25, 125, -30),
A vertex at (5, 25, 125, 30),
A vertex at (6, 36, 216, -60),
A vertex at (6, 36, 216, 60))
</pre><p>
<code>W2</code> has vertices with integer coordinates
</p>
Ticketgh-kliemWed, 24 Jul 2019 21:59:40 GMT
https://trac.sagemath.org/ticket/27973#comment:20
https://trac.sagemath.org/ticket/27973#comment:20
<p>
Is this <code>ZZ.one()</code> really needed? Base extend should work recognize <code>1</code> as well.
</p>
<p>
Can you add <code>base_ring=self.base_ring()</code> and same for backend to initialization of L. (Setting up the correct base ring right away, avoids coercion for the product to my understanding.)
</p>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/27973#comment:19" title="Comment 19">gh-LaisRast</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/27973#comment:18" title="Comment 18">gh-kliem</a>:
</p>
<blockquote class="citation">
<p>
What about normaliz with base ring ZZ and width 5/2 (even worse 4/2)? (I suspect backend will not be preserved).
</p>
<p>
What about the examples of <a class="closed ticket" href="https://trac.sagemath.org/ticket/25097" title="enhancement: Algebraic polyhedra with Normaliz / e-antic (closed: fixed)">#25097</a>. Do they work?
</p>
<p>
(Sorry, still can't test it myself).
</p>
</blockquote>
<p>
The polyhedron <code>H</code> is the responsible for changing the base ring and the backend. The following should fix the problem (up to change of base ring form ZZ to QQ, see <code>W2</code> below):
</p>
<div class="wiki-code"><div class="code"><pre><span class="gd">- def wedge(self, face, width=1):
</span><span class="gi">+ def wedge(self, face, width=None):
</span> r"""
Return the wedge over a ``face`` of the polytope ``self``.
<span class="gu">@@ -4205,6 +4205,10 @@ class Polyhedron_base(Element):
</span> sage: P.wedge(P.faces(2)[0], width=RDF(1)).base_ring()
Real Double Field
"""
<span class="gi">+ if width is None:
+ width = ZZ.one()
+
</span> if not self.is_compact():
raise ValueError("polyhedron 'self' must be a polytope")
<span class="gu">@@ -4223,7 +4227,11 @@ class Polyhedron_base(Element):
</span>
L = Polyhedron(lines=[[1]])
Q = self.product(L)
<span class="gd">- H = Polyhedron(ieqs=[F_Hrep + [width], F_Hrep + [-width]])
</span><span class="gi">+
+ parent = self.parent().base_extend(width, ambient_dim=self.ambient_dim()+1)
+ ieqs = [F_Hrep + [width], F_Hrep + [-width]]
+ H = parent.element_class(parent, None, [ieqs, None])
</span> return Q.intersection(H)
</pre></div></div><p>
Some examples:
</p>
<pre class="wiki">sage: P = polytopes.cyclic_polytope(3,7, base_ring=ZZ, backend='normaliz')
sage: W1 = P.wedge(P.faces(2)[0]); W1.base_ring(); W1.backend()
Integer Ring
'normaliz'
sage: W2 = P.wedge(P.faces(2)[0], width=5/2); W2.base_ring(); W2.backend()
Rational Field
'normaliz'
sage: W2 = P.wedge(P.faces(2)[0], width=4/2); W2.base_ring(); W2.backend()
Rational Field
'normaliz'
sage: W2.vertices()
(A vertex at (0, 0, 0, 0),
A vertex at (1, 1, 1, 0),
A vertex at (2, 4, 8, 0),
A vertex at (3, 9, 27, -3),
A vertex at (3, 9, 27, 3),
A vertex at (4, 16, 64, -12),
A vertex at (4, 16, 64, 12),
A vertex at (5, 25, 125, -30),
A vertex at (5, 25, 125, 30),
A vertex at (6, 36, 216, -60),
A vertex at (6, 36, 216, 60))
</pre><p>
<code>W2</code> has vertices with integer coordinates
</p>
</blockquote>
TicketjipilabThu, 25 Jul 2019 07:18:12 GMT
https://trac.sagemath.org/ticket/27973#comment:21
https://trac.sagemath.org/ticket/27973#comment:21
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/27973#comment:18" title="Comment 18">gh-kliem</a>:
</p>
<blockquote class="citation">
<p>
What about normaliz with base ring ZZ and width 5/2 (even worse 4/2)? (I suspect backend will not be preserved).
</p>
</blockquote>
<p>
A note: in Sage <code>4/2</code> is rational:
</p>
<pre class="wiki">sage: type(4/2)
<class 'sage.rings.rational.Rational'>
</pre><p>
and it should be like that, not to create nightmares.
</p>
<p>
Hence, taking <code>width=4/2</code>, the expected behavior is <em>really</em> to change the base ring to rational numbers.
</p>
<p>
In Sage dividing two <code>Integers</code> yields an element in the <a class="missing wiki">FractionField?</a>, i.e. the rationals. It is the users responsibility to know these things. Just like <code>2.0</code> is not an integer.
</p>
<p>
That said, it is completely fine to have <code>base_ring=QQ</code> but integral vertices. The goal of base ring is not to steadily represent the smallest ring in which the vertices lay in.
</p>
Ticketgh-kliemThu, 25 Jul 2019 07:58:50 GMT
https://trac.sagemath.org/ticket/27973#comment:22
https://trac.sagemath.org/ticket/27973#comment:22
<p>
I was aware of <code>4/2</code> being rational.
I just find it awful to change the backend when you enter rational width.
The backend should never change unintentionally unless necessary (so if you enter <code>width=2.0</code> the backend will change to cdd, which I would consider the expected behavior.)
</p>
<p>
It's just annoying when you want to use <code>normaliz</code> and every operation ignores your preference and you have to change backend over and over (and even worse calculations might take longer time with <code>ppl</code>, which you decided not to use in the first place).
</p>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/27973#comment:21" title="Comment 21">jipilab</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/27973#comment:18" title="Comment 18">gh-kliem</a>:
</p>
<blockquote class="citation">
<p>
What about normaliz with base ring ZZ and width 5/2 (even worse 4/2)? (I suspect backend will not be preserved).
</p>
</blockquote>
<p>
A note: in Sage <code>4/2</code> is rational:
</p>
<p>
sage: type(4/2)
<class 'sage.rings.rational.Rational'>
}}}
</p>
<p>
and it should be like that, not to create nightmares.
</p>
<p>
Hence, taking <code>width=4/2</code>, the expected behavior is <em>really</em> to change the base ring to rational numbers.
</p>
<p>
In Sage dividing two <code>Integers</code> yields an element in the <a class="missing wiki">FractionField?</a>, i.e. the rationals. It is the users responsibility to know these things. Just like <code>2.0</code> is not an integer.
</p>
<p>
That said, it is completely fine to have <code>base_ring=QQ</code> but integral vertices. The goal of base ring is not to steadily represent the smallest ring in which the vertices lay in.
</p>
</blockquote>
TicketjipilabThu, 25 Jul 2019 08:13:43 GMT
https://trac.sagemath.org/ticket/27973#comment:23
https://trac.sagemath.org/ticket/27973#comment:23
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/27973#comment:22" title="Comment 22">gh-kliem</a>:
</p>
<blockquote class="citation">
<p>
I was aware of <code>4/2</code> being rational.
I just find it awful to change the backend when you enter rational width.
The backend should never change unintentionally unless necessary (so if you enter <code>width=2.0</code> the backend will change to cdd, which I would consider the expected behavior.)
</p>
<p>
It's just annoying when you want to use <code>normaliz</code> and every operation ignores your preference and you have to change backend over and over (and even worse calculations might take longer time with <code>ppl</code>, which you decided not to use in the first place).
</p>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/27973#comment:21" title="Comment 21">jipilab</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/27973#comment:18" title="Comment 18">gh-kliem</a>:
</p>
<blockquote class="citation">
<p>
What about normaliz with base ring ZZ and width 5/2 (even worse 4/2)? (I suspect backend will not be preserved).
</p>
</blockquote>
<p>
A note: in Sage <code>4/2</code> is rational:
</p>
<p>
sage: type(4/2)
<class 'sage.rings.rational.Rational'>
}}}
</p>
<p>
and it should be like that, not to create nightmares.
</p>
<p>
Hence, taking <code>width=4/2</code>, the expected behavior is <em>really</em> to change the base ring to rational numbers.
</p>
<p>
In Sage dividing two <code>Integers</code> yields an element in the <a class="missing wiki">FractionField?</a>, i.e. the rationals. It is the users responsibility to know these things. Just like <code>2.0</code> is not an integer.
</p>
<p>
That said, it is completely fine to have <code>base_ring=QQ</code> but integral vertices. The goal of base ring is not to steadily represent the smallest ring in which the vertices lay in.
</p>
</blockquote>
</blockquote>
<p>
Of course, of course. The only thing to do is to carry the backend to the wedge, no big deal...
</p>
TicketgitThu, 25 Jul 2019 09:27:54 GMTcommit changed
https://trac.sagemath.org/ticket/27973#comment:24
https://trac.sagemath.org/ticket/27973#comment:24
<ul>
<li><strong>commit</strong>
changed from <em>417bfac337f17e93494d8f31b9031f9311cee423</em> to <em>7653fb8d21fc31d7ab34ff2c1c6da050934adef9</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=00f225333846d3559bcf9caefc62a35e0b8b918a"><span class="icon"></span>00f2253</a></td><td><code>polyhedron H now preserves backend now</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=09597bdff5713b097959a839fc6f24f4134e0f90"><span class="icon"></span>09597bd</a></td><td><code>backend should be preserved now</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=7653fb8d21fc31d7ab34ff2c1c6da050934adef9"><span class="icon"></span>7653fb8</a></td><td><code>Now should work if width is in RDF</code>
</td></tr></table>
Ticketgh-LaisRastThu, 25 Jul 2019 09:29:47 GMT
https://trac.sagemath.org/ticket/27973#comment:25
https://trac.sagemath.org/ticket/27973#comment:25
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/27973#comment:20" title="Comment 20">gh-kliem</a>:
</p>
<blockquote class="citation">
<p>
Base extend should work recognize <code>1</code> as well.
</p>
</blockquote>
<p>
Not anymore after the last commit I did. <code>ZZ.one()</code> is really needed now. The <code>width</code> should have a <code>base_ring</code>method in order for the wedge to work.
</p>
<blockquote class="citation">
<p>
Can you add <code>base_ring=self.base_ring()</code> and same for backend to initialization of L. (Setting up the correct base ring right away, avoids coercion for the product to my understanding.)
</p>
</blockquote>
<p>
This might produce problems due to the following behavior:
</p>
<pre class="wiki">sage: Polyhedron(lines=[[1]])
A 1-dimensional polyhedron in ZZ^1 defined as the convex hull of 1 vertex and 1 line
sage: Polyhedron(lines=[[1]], base_ring=AA)
The empty polyhedron in AA^1
sage: Polyhedron(lines=[[1]], base_ring=AA, backend='normaliz')
A 1-dimensional polyhedron in AA^1 defined as the convex hull of 1 vertex and 1 line
</pre><p>
The backend should now be preserved as long as this is possible. The base ring will change to the field of fractions of the current base ring, if width takes the default value 1. This is really needed because the base ring for the vertices is either the base ring for the ieqs or its field of fractions
</p>
<hr />
<p>
New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=00f225333846d3559bcf9caefc62a35e0b8b918a"><span class="icon"></span>00f2253</a></td><td><code>polyhedron H now preserves backend now</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=09597bdff5713b097959a839fc6f24f4134e0f90"><span class="icon"></span>09597bd</a></td><td><code>backend should be preserved now</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=7653fb8d21fc31d7ab34ff2c1c6da050934adef9"><span class="icon"></span>7653fb8</a></td><td><code>Now should work if width is in RDF</code>
</td></tr></table>
Ticketgh-LaisRastThu, 25 Jul 2019 09:45:15 GMTstatus changed
https://trac.sagemath.org/ticket/27973#comment:26
https://trac.sagemath.org/ticket/27973#comment:26
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
</ul>
Ticketgh-kliemThu, 25 Jul 2019 11:15:35 GMT
https://trac.sagemath.org/ticket/27973#comment:27
https://trac.sagemath.org/ticket/27973#comment:27
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/27973#comment:25" title="Comment 25">gh-LaisRast</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/27973#comment:20" title="Comment 20">gh-kliem</a>:
</p>
<blockquote class="citation">
<p>
Base extend should work recognize <code>1</code> as well.
</p>
</blockquote>
<p>
Not anymore after the last commit I did. <code>ZZ.one()</code> is really needed now. The <code>width</code> should have a <code>base_ring</code>method in order for the wedge to work.
</p>
<blockquote class="citation">
<p>
Can you add <code>base_ring=self.base_ring()</code> and same for backend to initialization of L. (Setting up the correct base ring right away, avoids coercion for the product to my understanding.)
</p>
</blockquote>
<p>
This might produce problems due to the following behavior:
</p>
<pre class="wiki">sage: Polyhedron(lines=[[1]])
A 1-dimensional polyhedron in ZZ^1 defined as the convex hull of 1 vertex and 1 line
sage: Polyhedron(lines=[[1]], base_ring=AA)
The empty polyhedron in AA^1
sage: Polyhedron(lines=[[1]], base_ring=AA, backend='normaliz')
A 1-dimensional polyhedron in AA^1 defined as the convex hull of 1 vertex and 1 line
</pre></blockquote>
<p>
I think that's a bug.
</p>
<blockquote class="citation">
<p>
The backend should now be preserved as long as this is possible. The base ring will change to the field of fractions of the current base ring, if width takes the default value 1. This is really needed because the base ring for the vertices is either the base ring for the ieqs or its field of fractions
</p>
<hr />
<p>
New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=00f225333846d3559bcf9caefc62a35e0b8b918a"><span class="icon"></span>00f2253</a></td><td><code>polyhedron H now preserves backend now</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=09597bdff5713b097959a839fc6f24f4134e0f90"><span class="icon"></span>09597bd</a></td><td><code>backend should be preserved now</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=7653fb8d21fc31d7ab34ff2c1c6da050934adef9"><span class="icon"></span>7653fb8</a></td><td><code>Now should work if width is in RDF</code>
</td></tr></table>
</blockquote>
Ticketgh-kliemThu, 25 Jul 2019 11:29:57 GMTstatus changed
https://trac.sagemath.org/ticket/27973#comment:28
https://trac.sagemath.org/ticket/27973#comment:28
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
Most importantly the <code>normaliz</code> tests should be marked optional as <code>pynormaliz</code> cannot be assumed to be installed.
Alternatively, you can switch to backend <code>field</code> for the tests, this demonstrates as well that the backend is preserved.
</p>
<p>
The current code does not work with width a python integer ect.
How about <code>parent = self.parent().base_extend(width/1, …</code>, I believe this works as well.
Then a default <code>width=1</code> would be fine as well.
As of <a class="closed ticket" href="https://trac.sagemath.org/ticket/27926" title="enhancement: Preserve backend for polytopal constructions (closed: fixed)">#27926</a> <code>parent.base_extend</code> works with elements of rings and numbers that can be interpreted as such.
</p>
Ticketgh-LaisRastThu, 25 Jul 2019 11:59:10 GMT
https://trac.sagemath.org/ticket/27973#comment:29
https://trac.sagemath.org/ticket/27973#comment:29
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/27973#comment:28" title="Comment 28">gh-kliem</a>:
</p>
<blockquote class="citation">
<p>
Most importantly the <code>normaliz</code> tests should be marked optional as <code>pynormaliz</code> cannot be assumed to be installed.
Alternatively, you can switch to backend <code>field</code> for the tests, this demonstrates as well that the backend is preserved.
</p>
</blockquote>
<p>
I switched to <code>field</code>.
</p>
<blockquote class="citation">
<p>
The current code does not work with width a python integer ect.
How about <code>parent = self.parent().base_extend(width/1, …</code>, I believe this works as well.
Then a default <code>width=1</code> would be fine as well.
As of <a class="closed ticket" href="https://trac.sagemath.org/ticket/27926" title="enhancement: Preserve backend for polytopal constructions (closed: fixed)">#27926</a> <code>parent.base_extend</code> works with elements of rings and numbers that can be interpreted as such.
</p>
</blockquote>
<p>
In python3 (resp. python2), <code>x = 1/1; type(x)</code> gives <code><class 'float'></code> (resp. <code><type 'int'></code>), which does not have a <code>.base_ring()</code>. I need <code>.base_ring()</code> so I can find its <code>.fraction_field()</code>.
</p>
TicketgitThu, 25 Jul 2019 12:01:28 GMTcommit changed
https://trac.sagemath.org/ticket/27973#comment:30
https://trac.sagemath.org/ticket/27973#comment:30
<ul>
<li><strong>commit</strong>
changed from <em>7653fb8d21fc31d7ab34ff2c1c6da050934adef9</em> to <em>c77c1af1ff8732512b3cd25fe6bdc4a138041c34</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=c77c1af1ff8732512b3cd25fe6bdc4a138041c34"><span class="icon"></span>c77c1af</a></td><td><code>normaliz -> field in tests</code>
</td></tr></table>
Ticketgh-LaisRastThu, 25 Jul 2019 12:20:15 GMTstatus changed
https://trac.sagemath.org/ticket/27973#comment:31
https://trac.sagemath.org/ticket/27973#comment:31
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
</ul>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/27973#comment:29" title="Comment 29">gh-LaisRast</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/27973#comment:28" title="Comment 28">gh-kliem</a>:
</p>
<blockquote class="citation">
<p>
Most importantly the <code>normaliz</code> tests should be marked optional as <code>pynormaliz</code> cannot be assumed to be installed.
Alternatively, you can switch to backend <code>field</code> for the tests, this demonstrates as well that the backend is preserved.
</p>
</blockquote>
<p>
I switched to <code>field</code>.
</p>
<blockquote class="citation">
<p>
The current code does not work with width a python integer ect.
How about <code>parent = self.parent().base_extend(width/1, …</code>, I believe this works as well.
Then a default <code>width=1</code> would be fine as well.
As of <a class="closed ticket" href="https://trac.sagemath.org/ticket/27926" title="enhancement: Preserve backend for polytopal constructions (closed: fixed)">#27926</a> <code>parent.base_extend</code> works with elements of rings and numbers that can be interpreted as such.
</p>
</blockquote>
<p>
In python3 (resp. python2), <code>x = 1/1; type(x)</code> gives <code><class 'float'></code> (resp. <code><type 'int'></code>), which does not have a <code>.base_ring()</code>. I need <code>.base_ring()</code> so I can find its <code>.fraction_field()</code>.
</p>
</blockquote>
<p>
Having <code>ZZ.one()</code> as default instead of python <code>1</code> solves the problem for the default value. If the value of <code>width</code> is not the default value, then it is a sage ring element. This solves the problem for non-default values.
</p>
Ticketgh-kliemThu, 25 Jul 2019 12:23:53 GMT
https://trac.sagemath.org/ticket/27973#comment:32
https://trac.sagemath.org/ticket/27973#comment:32
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/27973#comment:29" title="Comment 29">gh-LaisRast</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/27973#comment:28" title="Comment 28">gh-kliem</a>:
</p>
<blockquote class="citation">
<p>
Most importantly the <code>normaliz</code> tests should be marked optional as <code>pynormaliz</code> cannot be assumed to be installed.
Alternatively, you can switch to backend <code>field</code> for the tests, this demonstrates as well that the backend is preserved.
</p>
</blockquote>
<p>
I switched to <code>field</code>.
</p>
<blockquote class="citation">
<p>
The current code does not work with width a python integer ect.
How about <code>parent = self.parent().base_extend(width/1, …</code>, I believe this works as well.
Then a default <code>width=1</code> would be fine as well.
As of <a class="closed ticket" href="https://trac.sagemath.org/ticket/27926" title="enhancement: Preserve backend for polytopal constructions (closed: fixed)">#27926</a> <code>parent.base_extend</code> works with elements of rings and numbers that can be interpreted as such.
</p>
</blockquote>
<p>
In python3 (resp. python2), <code>x = 1/1; type(x)</code> gives <code><class 'float'></code> (resp. <code><type 'int'></code>), which does not have a <code>.base_ring()</code>. I need <code>.base_ring()</code> so I can find its <code>.fraction_field()</code>.
</p>
</blockquote>
<p>
<code>parent._coerce_base_ring(1/1)</code> gives rational field, which tells me that base extend works fine.
Don't worry about passing a ring to <code>Polyhedra.base_extend</code>.
Probably you should pass <code>1/width</code> as argument <code>base_ring</code>:
</p>
<div class="wiki-code"><div class="code"><pre><span class="gd">- parent = self.parent().base_extend(width.base_ring().fraction_field(),\
</span><span class="gi">+ parent = self.parent().base_extend(1/width,\
</span> ambient_dim=self.ambient_dim()+1)
</pre></div></div><p>
This extends the ring of parent, such that <code>1/width</code> is an element.
There is a number of occasions, where I used <code>base_extend</code> this way to have polyhedral operations respect the base ring.
</p>
Ticketgh-kliemThu, 25 Jul 2019 12:41:00 GMT
https://trac.sagemath.org/ticket/27973#comment:33
https://trac.sagemath.org/ticket/27973#comment:33
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/27973#comment:31" title="Comment 31">gh-LaisRast</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/27973#comment:29" title="Comment 29">gh-LaisRast</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/27973#comment:28" title="Comment 28">gh-kliem</a>:
</p>
<blockquote class="citation">
<p>
Most importantly the <code>normaliz</code> tests should be marked optional as <code>pynormaliz</code> cannot be assumed to be installed.
Alternatively, you can switch to backend <code>field</code> for the tests, this demonstrates as well that the backend is preserved.
</p>
</blockquote>
<p>
I switched to <code>field</code>.
</p>
<blockquote class="citation">
<p>
The current code does not work with width a python integer ect.
How about <code>parent = self.parent().base_extend(width/1, …</code>, I believe this works as well.
Then a default <code>width=1</code> would be fine as well.
As of <a class="closed ticket" href="https://trac.sagemath.org/ticket/27926" title="enhancement: Preserve backend for polytopal constructions (closed: fixed)">#27926</a> <code>parent.base_extend</code> works with elements of rings and numbers that can be interpreted as such.
</p>
</blockquote>
<p>
In python3 (resp. python2), <code>x = 1/1; type(x)</code> gives <code><class 'float'></code> (resp. <code><type 'int'></code>), which does not have a <code>.base_ring()</code>. I need <code>.base_ring()</code> so I can find its <code>.fraction_field()</code>.
</p>
</blockquote>
<p>
Having <code>ZZ.one()</code> as default instead of python <code>1</code> solves the problem for the default value. If the value of <code>width</code> is not the default value, then it is a sage ring element. This solves the problem for non-default values.
</p>
</blockquote>
<p>
No. If you write a python script that uses this method, you will have to import <code>Integer</code> from sage as well to be able to pass <code>width</code>.
Something as <code>1l</code> or <code>1L</code> or <code>float(0.9)</code> should work as well.
</p>
<p>
Actually you need to use <code>ZZ.one()/width</code> (not <code>1/width</code>), which should do the trick. Sorry about the confusion.
Alternatively, you find a method to map <code>width</code> to a sage ring element and then still do the fraction field.
</p>
Ticketgh-kliemThu, 25 Jul 2019 12:42:25 GMTstatus changed
https://trac.sagemath.org/ticket/27973#comment:34
https://trac.sagemath.org/ticket/27973#comment:34
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
Please allow python integers (and floats) as input for width.
</p>
TicketgitThu, 25 Jul 2019 12:48:12 GMTcommit changed
https://trac.sagemath.org/ticket/27973#comment:35
https://trac.sagemath.org/ticket/27973#comment:35
<ul>
<li><strong>commit</strong>
changed from <em>c77c1af1ff8732512b3cd25fe6bdc4a138041c34</em> to <em>ccce5f2c2fc9c63d307e799572fcce581079a569</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=ccce5f2c2fc9c63d307e799572fcce581079a569"><span class="icon"></span>ccce5f2</a></td><td><code>python ints and floats can be used for width</code>
</td></tr></table>
Ticketgh-LaisRastThu, 25 Jul 2019 12:48:58 GMTstatus changed
https://trac.sagemath.org/ticket/27973#comment:36
https://trac.sagemath.org/ticket/27973#comment:36
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
</ul>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/27973#comment:33" title="Comment 33">gh-kliem</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/27973#comment:31" title="Comment 31">gh-LaisRast</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/27973#comment:29" title="Comment 29">gh-LaisRast</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/27973#comment:28" title="Comment 28">gh-kliem</a>:
</p>
<blockquote class="citation">
<p>
Most importantly the <code>normaliz</code> tests should be marked optional as <code>pynormaliz</code> cannot be assumed to be installed.
Alternatively, you can switch to backend <code>field</code> for the tests, this demonstrates as well that the backend is preserved.
</p>
</blockquote>
<p>
I switched to <code>field</code>.
</p>
<blockquote class="citation">
<p>
The current code does not work with width a python integer ect.
How about <code>parent = self.parent().base_extend(width/1, …</code>, I believe this works as well.
Then a default <code>width=1</code> would be fine as well.
As of <a class="closed ticket" href="https://trac.sagemath.org/ticket/27926" title="enhancement: Preserve backend for polytopal constructions (closed: fixed)">#27926</a> <code>parent.base_extend</code> works with elements of rings and numbers that can be interpreted as such.
</p>
</blockquote>
<p>
In python3 (resp. python2), <code>x = 1/1; type(x)</code> gives <code><class 'float'></code> (resp. <code><type 'int'></code>), which does not have a <code>.base_ring()</code>. I need <code>.base_ring()</code> so I can find its <code>.fraction_field()</code>.
</p>
</blockquote>
<p>
Having <code>ZZ.one()</code> as default instead of python <code>1</code> solves the problem for the default value. If the value of <code>width</code> is not the default value, then it is a sage ring element. This solves the problem for non-default values.
</p>
</blockquote>
<p>
No. If you write a python script that uses this method, you will have to import <code>Integer</code> from sage as well to be able to pass <code>width</code>.
Something as <code>1l</code> or <code>1L</code> or <code>float(0.9)</code> should work as well.
</p>
<p>
Actually you need to use <code>ZZ.one()/width</code> (not <code>1/width</code>), which should do the trick. Sorry about the confusion.
Alternatively, you find a method to map <code>width</code> to a sage ring element and then still do the fraction field.
</p>
</blockquote>
<p>
This is actually a good trick to deal with python numbers.
</p>
TicketgitThu, 25 Jul 2019 12:54:47 GMTcommit changed
https://trac.sagemath.org/ticket/27973#comment:37
https://trac.sagemath.org/ticket/27973#comment:37
<ul>
<li><strong>commit</strong>
changed from <em>ccce5f2c2fc9c63d307e799572fcce581079a569</em> to <em>6ba559456a3770c5517956db2d7ae1ed44a8d717</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=6ba559456a3770c5517956db2d7ae1ed44a8d717"><span class="icon"></span>6ba5594</a></td><td><code>width.base_ring().fraction_field() -> ZZ.one()/width</code>
</td></tr></table>
Ticketgh-LaisRastThu, 25 Jul 2019 12:56:10 GMTdescription changed
https://trac.sagemath.org/ticket/27973#comment:38
https://trac.sagemath.org/ticket/27973#comment:38
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/27973?action=diff&version=38">diff</a>)
</li>
</ul>
TicketjipilabThu, 25 Jul 2019 13:27:18 GMTmilestone set
https://trac.sagemath.org/ticket/27973#comment:39
https://trac.sagemath.org/ticket/27973#comment:39
<ul>
<li><strong>milestone</strong>
set to <em>sage-8.9</em>
</li>
</ul>
TicketjipilabThu, 25 Jul 2019 13:41:35 GMT
https://trac.sagemath.org/ticket/27973#comment:40
https://trac.sagemath.org/ticket/27973#comment:40
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/27973#comment:27" title="Comment 27">gh-kliem</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/27973#comment:25" title="Comment 25">gh-LaisRast</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/27973#comment:20" title="Comment 20">gh-kliem</a>:
</p>
<blockquote class="citation">
<p>
Base extend should work recognize <code>1</code> as well.
</p>
</blockquote>
<p>
Not anymore after the last commit I did. <code>ZZ.one()</code> is really needed now. The <code>width</code> should have a <code>base_ring</code>method in order for the wedge to work.
</p>
<blockquote class="citation">
<p>
Can you add <code>base_ring=self.base_ring()</code> and same for backend to initialization of L. (Setting up the correct base ring right away, avoids coercion for the product to my understanding.)
</p>
</blockquote>
<p>
This might produce problems due to the following behavior:
</p>
<pre class="wiki">sage: Polyhedron(lines=[[1]])
A 1-dimensional polyhedron in ZZ^1 defined as the convex hull of 1 vertex and 1 line
sage: Polyhedron(lines=[[1]], base_ring=AA)
The empty polyhedron in AA^1
sage: Polyhedron(lines=[[1]], base_ring=AA, backend='normaliz')
A 1-dimensional polyhedron in AA^1 defined as the convex hull of 1 vertex and 1 line
</pre></blockquote>
<p>
I think that's a bug.
</p>
</blockquote>
<p>
This is definitely a bug.
</p>
TicketjipilabThu, 25 Jul 2019 13:51:08 GMT
https://trac.sagemath.org/ticket/27973#comment:41
https://trac.sagemath.org/ticket/27973#comment:41
<blockquote class="citation">
<p>
Actually you need to use <code>ZZ.one()/width</code> (not <code>1/width</code>), which should do the trick. Sorry about the confusion.
Alternatively, you find a method to map <code>width</code> to a sage ring element and then still do the fraction field.
</p>
</blockquote>
<p>
I do not get at all all this fuss.
</p>
<p>
The default of <code>width</code> should be set to <code>None</code>. If no value is given, the algorithm will fetch the base ring of the object and take <code>.one()</code> of that base ring and continue with that value.
</p>
<p>
If the user gives a weird value for the width, that's the user's problem (the whole <code>Polyhedron</code> class is based on this principle). It is not at all expected that the base ring is preserved. Only if possible (which is handled by the intersection method...
</p>
<p>
The only thing that matters is the backend. Thus the returned polyhedron should have the right backend...
</p>
<p>
I fail to see the issue here.
</p>
TicketjipilabThu, 25 Jul 2019 13:56:03 GMT
https://trac.sagemath.org/ticket/27973#comment:42
https://trac.sagemath.org/ticket/27973#comment:42
<p>
... in particular, I do not see at all why a <code>base_extend</code> would be necessary.
</p>
Ticketgh-kliemThu, 25 Jul 2019 14:41:33 GMT
https://trac.sagemath.org/ticket/27973#comment:43
https://trac.sagemath.org/ticket/27973#comment:43
<p>
<code>H</code> should be well-defined and with correct backend. This is what we need <code>base_extend</code> for.
I didn't check if we really need the value <code>1/width</code>.
I don't find a python integer to be a overly strange input.
Especially, since we already put in the effort to make our default work.
</p>
<p>
Using standard constructor for <code>H</code> with backend argument can result in an error, when the backend doesn't support <code>width</code>.
Standard constructor without backend argument, will not preserve backend, e.g. with <code>self</code> being integral.
</p>
<p>
<code>base_extend</code> does preserve backend whenever possible, which is exactly what we want.
</p>
<p>
Btw, can't we just write down all equations and inequalities right away.
This saves the time of calculating double description for two (possibly large) intermediate polyhedra.
</p>
TicketjipilabThu, 25 Jul 2019 15:16:58 GMT
https://trac.sagemath.org/ticket/27973#comment:44
https://trac.sagemath.org/ticket/27973#comment:44
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/27973#comment:43" title="Comment 43">gh-kliem</a>:
</p>
<blockquote class="citation">
<p>
<code>H</code> should be well-defined and with correct backend. This is what we need <code>base_extend</code> for.
</p>
</blockquote>
<p>
<code>H</code> is a totally well defined object on whatever reasonable given value of <code>width</code> that is given by the user. There is no such thing as correct backend at this stage. All you would do is try to do a good guess before <code>intersection</code> will proceed to do exactly the same, but with the help of coercion. So why try to do things twice?
</p>
<p>
If the user doesn't say a word, then for sure we should just take a width from the same base ring. Then, the story with backend is irrelevant since this should be taken care of in the intersection method, and not in this specific place.
</p>
<blockquote class="citation">
<p>
I didn't check if we really need the value <code>1/width</code>.
I don't find a python integer to be a overly strange input.
Especially, since we already put in the effort to make our default work.
</p>
</blockquote>
<p>
The code is barely 15 lines long... ;-)
</p>
<blockquote class="citation">
<p>
Using standard constructor for <code>H</code> with backend argument can result in an error, when the backend doesn't support <code>width</code>.
</p>
</blockquote>
<p>
Now I see what you mean. But again that business should be taken care of by intersection, and not here.
</p>
<blockquote class="citation">
<p>
Standard constructor without backend argument, will not preserve backend, e.g. with <code>self</code> being integral.
</p>
<p>
<code>base_extend</code> does preserve backend whenever possible, which is exactly what we want.
</p>
</blockquote>
<p>
Agreed. But this is a hack, and I do not like that solution. Further, one line after <code>H</code> is defined it is passed right away to intersection.
</p>
<blockquote class="citation">
<p>
Btw, can't we just write down all equations and inequalities right away.
This saves the time of calculating double description for two (possibly large) intermediate polyhedra.
</p>
</blockquote>
<p>
Yes, and the long term idea is to have intersection do this kind of redundancy checks using <code>normaliz</code> tools. (long term...) Once adding inequalities dynamically will be readily available in Sage, we can talk about it again. For now, I don't think we have to deal with this in this ticket.
</p>
<p>
In the end, the wedge is the intersection of an infinite prism over the given polyhedron (trivial to keep base ring and backend) and an infinite <code>keil</code> defined by two inequalities. The base ring of this <code>keil</code> is decided by the type of <code>width</code>, and the backend should also be decided from the type of <code>width</code>.
</p>
<p>
Then, the decision for the backend of the intersection should be delegated to <code>.intersection</code> method. Why all the fuss here in wedge? If the user gives a float width and had normaliz as a backend, why should it stay normaliz? It can't!
</p>
<p>
The coercion will just figure out the right object and backend... This is already taken care of in intersection.
</p>
<p>
The following illustrates exactly the behavior that I expect to happen in <code>wedge</code>:
</p>
<pre class="wiki">sage: P = Polyhedron(rays=[[1,0],[0,1]],base_ring=RDF)
sage: Q = Polyhedron(rays=[[-1,0],[0,1]],vertices=[[1,0]],backend='normaliz')
sage: P & Q
A 2-dimensional polyhedron in RDF^2 defined as the convex hull of 2 vertices and 1 ray
sage: P.backend()
'cdd'
sage: Q.backend()
'normaliz'
</pre>
Ticketgh-kliemThu, 25 Jul 2019 17:48:04 GMT
https://trac.sagemath.org/ticket/27973#comment:45
https://trac.sagemath.org/ticket/27973#comment:45
<p>
The problem is not float. A float is going to change backend to <code>cdd</code>, which is fine.
</p>
<p>
Let <code>P</code> with parent <code>Polyhedra_normaliz_ZZ</code> and <code>Q</code> with parent <code>Polyhedra_ppl_QQ</code> then coercion will lead the intersection to be an element of <code>Polyhedra_ppl_QQ</code>, because there is a map in exactly one direction.
</p>
<p>
Hence, intersection might change the backend (it might prefer backend of <code>self</code> or <code>other</code> depending on the involved rings).
However, I would expect a user to create all polyhedra with his preferred backend, so that shouldn't cause issues.
</p>
<p>
Now, if we create a polyhedron <code>H</code> with default backend (and not what the user chose as backend of <code>self</code>) this might cause the <code>backend</code> to change. I think one could only prevent this by not using coercion for intersection.
</p>
TicketjipilabThu, 25 Jul 2019 17:57:55 GMT
https://trac.sagemath.org/ticket/27973#comment:46
https://trac.sagemath.org/ticket/27973#comment:46
<blockquote class="citation">
<p>
Now, if we create a polyhedron <code>H</code> with default backend (and not what the user chose as backend of <code>self</code>) this might cause the <code>backend</code> to change. I think one could only prevent this by not using coercion for intersection.
</p>
</blockquote>
<p>
I thought that the solution since the beginning is to query the backend of <code>self</code>and apply it to <code>H</code>. If it fails, well this is a bad day for the user, because the backend will have to change whatsoever, due to the type of input, which we should trust is what the user wants.
</p>
<p>
Hence, try to create <code>H</code> with the backend of self, it is fails, just create <code>H</code> using the type of the given width.
</p>
<p>
I would let <code>intersection</code> alone here and still trust it to do what is right when the time comes.
</p>
<p>
In the end, that the backend is not preserved by an operation which is not intended to, is not the end of the world. Is it?
</p>
Ticketgh-kliemThu, 25 Jul 2019 18:20:35 GMT
https://trac.sagemath.org/ticket/27973#comment:47
https://trac.sagemath.org/ticket/27973#comment:47
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/27973#comment:46" title="Comment 46">jipilab</a>:
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
Now, if we create a polyhedron <code>H</code> with default backend (and not what the user chose as backend of <code>self</code>) this might cause the <code>backend</code> to change. I think one could only prevent this by not using coercion for intersection.
</p>
</blockquote>
<p>
I thought that the solution since the beginning is to query the backend of <code>self</code>and apply it to <code>H</code>. If it fails, well this is a bad day for the user, because the backend will have to change whatsoever, due to the type of input, which we should trust is what the user wants.
</p>
<p>
Hence, try to create <code>H</code> with the backend of self, it is fails, just create <code>H</code> using the type of the given width.
</p>
</blockquote>
<p>
This is exactly what <code>base_extend</code> does. It changes the parent as little as possible. Of course you can also use the constructor with <code>try</code> and <code>except</code>, which is what <code>base_extend</code> does (but cached).
</p>
<blockquote class="citation">
<p>
I would let <code>intersection</code> alone here and still trust it to do what is right when the time comes.
</p>
</blockquote>
<p>
It will always prefer the backend of the polyhedron with larger ring due to coercion.
</p>
<blockquote class="citation">
<p>
In the end, that the backend is not preserved by an operation which is not intended to, is not the end of the world. Is it?
</p>
</blockquote>
<p>
It is a pain, if it could have been prevented. If working with large polyhedra, which are manageable with <code>normaliz</code> and take forever with <code>ppl</code> you don't want the backend to change.
</p>
<p>
To ask a user to to <code>base_extend</code> before wedge over face is very sudle.
</p>
Ticketgh-kliemThu, 25 Jul 2019 20:01:47 GMT
https://trac.sagemath.org/ticket/27973#comment:48
https://trac.sagemath.org/ticket/27973#comment:48
<p>
By the way, I don't really care how one initialized <code>H</code>. I just think it should have the backend of <code>self</code> if <code>width</code> admits it.
</p>
TicketjipilabSun, 28 Jul 2019 10:21:46 GMT
https://trac.sagemath.org/ticket/27973#comment:49
https://trac.sagemath.org/ticket/27973#comment:49
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/27973#comment:47" title="Comment 47">gh-kliem</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/27973#comment:46" title="Comment 46">jipilab</a>:
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
Now, if we create a polyhedron <code>H</code> with default backend (and not what the user chose as backend of <code>self</code>) this might cause the <code>backend</code> to change. I think one could only prevent this by not using coercion for intersection.
</p>
</blockquote>
<p>
I thought that the solution since the beginning is to query the backend of <code>self</code>and apply it to <code>H</code>. If it fails, well this is a bad day for the user, because the backend will have to change whatsoever, due to the type of input, which we should trust is what the user wants.
</p>
<p>
Hence, try to create <code>H</code> with the backend of self, it is fails, just create <code>H</code> using the type of the given width.
</p>
</blockquote>
<p>
This is exactly what <code>base_extend</code> does. It changes the parent as little as possible. Of course you can also use the constructor with <code>try</code> and <code>except</code>, which is what <code>base_extend</code> does (but cached).
</p>
</blockquote>
<p>
Ok, fine. But I would not do this business with <code>1/width</code>, etc.
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
I would let <code>intersection</code> alone here and still trust it to do what is right when the time comes.
</p>
</blockquote>
<p>
It will always prefer the backend of the polyhedron with larger ring due to coercion.
</p>
<blockquote class="citation">
<p>
In the end, that the backend is not preserved by an operation which is not intended to, is not the end of the world. Is it?
</p>
</blockquote>
<p>
It is a pain, if it could have been prevented. If working with large polyhedra, which are manageable with <code>normaliz</code> and take forever with <code>ppl</code> you don't want the backend to change.
</p>
</blockquote>
<p>
Obviously.
</p>
<blockquote class="citation">
<p>
To ask a user to to <code>base_extend</code> before wedge over face is very sudle.
</p>
</blockquote>
<p>
Sudle? I am not sure to understand what you mean. Do you have any concrete suggestion for the code now?
</p>
Ticketgh-kliemTue, 30 Jul 2019 12:57:02 GMT
https://trac.sagemath.org/ticket/27973#comment:50
https://trac.sagemath.org/ticket/27973#comment:50
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/27973#comment:49" title="Comment 49">jipilab</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/27973#comment:47" title="Comment 47">gh-kliem</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/27973#comment:46" title="Comment 46">jipilab</a>:
To ask a user to to <code>base_extend</code> before wedge over face is very sudle.
</p>
</blockquote>
<p>
Sudle? I am not sure to understand what you mean. Do you have any concrete suggestion for the code now?
</p>
</blockquote>
<p>
In many cases polyhedra will by default be set up with base ring <code>ZZ</code> like in
</p>
<pre class="wiki">sage: P = polytopes.simplex(backend='normaliz'); type(P)
<class 'sage.geometry.polyhedron.parent.Polyhedra_ZZ_normaliz_with_category.element_class'>
</pre><p>
If a user wants to keep his backend and we ask him to change the base ring to <code>QQ</code> before doing wedge over face, this is confusing.
</p>
TicketjipilabWed, 21 Aug 2019 14:03:19 GMTstatus changed
https://trac.sagemath.org/ticket/27973#comment:51
https://trac.sagemath.org/ticket/27973#comment:51
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
A few comments:
</p>
<ul><li>In the docstring <code>indicates how wide the resulted wedge should be</code>: I would say: <code>This parameter specifies how wide the wedge will be</code>.
</li></ul><ul><li><code>A (bounded) Polyhedron object</code> -> <code>A (bounded) polyhedron</code>
</li></ul><ul><li>Please provide me a simple argument as to why the field of fraction of the base ring should be used "by default" (i.e. when the width is 1). I would say that the resulting base ring should be determined by the constructor. Yes, this will depend on the input polytope, which is fine. Further, yes, the backend should be preserved if possible, which simply means that one should pass it to the constructor. What do I see wrong?
</li></ul><p>
Because we are using <code>Q.intersection(H)</code>, on top of what is done before, it is going to do a coercion to find the appropriate thing to do. I do not really understand why we force the parent of <code>H</code> to be the fraction field if it might not be necessary.
</p>
<ul><li>The text inside of the TEST is misleading since even if we give a different value to width, the base ring *will* change. ... so again, I am confused about how this is done. Further, the tests should provide a bit more demonstration as to how it preserves the backend (please show at least how it preserves 2 backends, with appropriate base rings).
</li></ul>
Ticketgh-kliemFri, 23 Aug 2019 21:21:15 GMT
https://trac.sagemath.org/ticket/27973#comment:52
https://trac.sagemath.org/ticket/27973#comment:52
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/27973#comment:51" title="Comment 51">jipilab</a>:
</p>
<blockquote class="citation">
<p>
A few comments:
</p>
<ul><li>In the docstring <code>indicates how wide the resulted wedge should be</code>: I would say: <code>This parameter specifies how wide the wedge will be</code>.
</li></ul><ul><li><code>A (bounded) Polyhedron object</code> -> <code>A (bounded) polyhedron</code>
</li></ul><ul><li>Please provide me a simple argument as to why the field of fraction of the base ring should be used "by default" (i.e. when the width is 1). I would say that the resulting base ring should be determined by the constructor. Yes, this will depend on the input polytope, which is fine. Further, yes, the backend should be preserved if possible, which simply means that one should pass it to the constructor. What do I see wrong?
</li></ul></blockquote>
<p>
I agree that is makes no sense to use the field of fractions, when <code>width</code> is 1. I guess we should use the field of fractions whenever <code>width</code> is not a unit.
</p>
<p>
If we just pass the <code>backend</code> to the constructor, we get an error if the value of <code>width</code> is not handled by the current backend. Is this the desired behavior? If you don't like the current setup, we can also just use <code>does_backend_handle_base_ring</code> from parent.py (its basically a cached version of doing <code>try ... except</code> for the constructor).
</p>
TicketjipilabMon, 26 Aug 2019 10:23:45 GMT
https://trac.sagemath.org/ticket/27973#comment:53
https://trac.sagemath.org/ticket/27973#comment:53
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/27973#comment:52" title="Comment 52">gh-kliem</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/27973#comment:51" title="Comment 51">jipilab</a>:
</p>
<blockquote class="citation">
<p>
A few comments:
</p>
<ul><li>In the docstring <code>indicates how wide the resulted wedge should be</code>: I would say: <code>This parameter specifies how wide the wedge will be</code>.
</li></ul><ul><li><code>A (bounded) Polyhedron object</code> -> <code>A (bounded) polyhedron</code>
</li></ul><ul><li>Please provide me a simple argument as to why the field of fraction of the base ring should be used "by default" (i.e. when the width is 1). I would say that the resulting base ring should be determined by the constructor. Yes, this will depend on the input polytope, which is fine. Further, yes, the backend should be preserved if possible, which simply means that one should pass it to the constructor. What do I see wrong?
</li></ul></blockquote>
<p>
I agree that is makes no sense to use the field of fractions, when <code>width</code> is 1. I guess we should use the field of fractions whenever <code>width</code> is not a unit.
</p>
<p>
If we just pass the <code>backend</code> to the constructor, we get an error if the value of <code>width</code> is not handled by the current backend. Is this the desired behavior?
</p>
</blockquote>
<p>
I guess not.
</p>
<blockquote class="citation">
<p>
If you don't like the current setup, we can also just use <code>does_backend_handle_base_ring</code> from parent.py (its basically a cached version of doing <code>try ... except</code> for the constructor).
</p>
</blockquote>
<p>
Yes, to me that's probably the best intermediate to proceed this way and let the intersection deal with the rest.
</p>
Ticketgh-kliemMon, 26 Aug 2019 11:57:47 GMTcommit, branch changed
https://trac.sagemath.org/ticket/27973#comment:54
https://trac.sagemath.org/ticket/27973#comment:54
<ul>
<li><strong>commit</strong>
changed from <em>6ba559456a3770c5517956db2d7ae1ed44a8d717</em> to <em>73dac038bb83c51824d02130c9d4f1930607b9f3</em>
</li>
<li><strong>branch</strong>
changed from <em>public/27973</em> to <em>public/27973-new</em>
</li>
</ul>
<p>
Merged with newest develop.
</p>
<hr />
<p>
New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=73dac038bb83c51824d02130c9d4f1930607b9f3"><span class="icon"></span>73dac03</a></td><td><code>add wedge method in Polyhedron class in base.py</code>
</td></tr></table>
TicketgitMon, 26 Aug 2019 12:40:25 GMTcommit changed
https://trac.sagemath.org/ticket/27973#comment:55
https://trac.sagemath.org/ticket/27973#comment:55
<ul>
<li><strong>commit</strong>
changed from <em>73dac038bb83c51824d02130c9d4f1930607b9f3</em> to <em>38944ad77e0a7ca760e97fcef85f2b957fe83eba</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=38944ad77e0a7ca760e97fcef85f2b957fe83eba"><span class="icon"></span>38944ad</a></td><td><code>simplified construction of H, small changes mostly in the documentation</code>
</td></tr></table>
Ticketgh-kliemMon, 26 Aug 2019 12:43:14 GMTstatus changed
https://trac.sagemath.org/ticket/27973#comment:56
https://trac.sagemath.org/ticket/27973#comment:56
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
</ul>
<p>
Tried to simplify construction of <code>H</code>.
</p>
<p>
Btw, I also tried to preserve the <code>base_ring</code> (when width is 1), but this did not work for the test in line 4205.
</p>
TicketjipilabMon, 26 Aug 2019 13:34:32 GMT
https://trac.sagemath.org/ticket/27973#comment:57
https://trac.sagemath.org/ticket/27973#comment:57
<p>
The sentence:
</p>
<div class="wiki-code"><div class="code"><pre><span class="gi">+ The base_ring will change to the field of fractions of the current
+ base_ring, unless width forces a different ring.
</span></pre></div></div><p>
is still confusing as it says that the base ring always will change to the field of fractions. What if it stays as ZZ? (which is possible). This should be fixed...
</p>
<p>
The rest seems to be good.
</p>
Ticketgh-kliemMon, 26 Aug 2019 13:54:47 GMT
https://trac.sagemath.org/ticket/27973#comment:58
https://trac.sagemath.org/ticket/27973#comment:58
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/27973#comment:57" title="Comment 57">jipilab</a>:
</p>
<blockquote class="citation">
<p>
The sentence:
</p>
<div class="wiki-code"><div class="code"><pre><span class="gi">+ The base_ring will change to the field of fractions of the current
+ base_ring, unless width forces a different ring.
</span></pre></div></div><p>
is still confusing as it says that the base ring always will change to the field of fractions. What if it stays as ZZ? (which is
</p>
</blockquote>
<p>
I don't think so. <code>H</code> is constructed from inequalities without specifying the basering. In this case the constructor coerces the base rings of all values and then takes the fraction field. If you want <code>ZZ</code> as basering when constructing a polyhedron from inequalities, you need to specify it for the constructor.
</p>
<blockquote class="citation">
<p>
This should be fixed...
</p>
<blockquote>
<p>
The rest seems to be good.
</p>
</blockquote>
</blockquote>
TicketjipilabMon, 26 Aug 2019 14:48:41 GMT
https://trac.sagemath.org/ticket/27973#comment:59
https://trac.sagemath.org/ticket/27973#comment:59
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/27973#comment:58" title="Comment 58">gh-kliem</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/27973#comment:57" title="Comment 57">jipilab</a>:
</p>
<blockquote class="citation">
<p>
The sentence:
</p>
<div class="wiki-code"><div class="code"><pre><span class="gi">+ The base_ring will change to the field of fractions of the current
+ base_ring, unless width forces a different ring.
</span></pre></div></div><p>
is still confusing as it says that the base ring always will change to the field of fractions. What if it stays as ZZ? (which is
</p>
</blockquote>
<p>
I don't think so. <code>H</code> is constructed from inequalities without specifying the basering. In this case the constructor coerces the base rings of all values and then takes the fraction field. If you want <code>ZZ</code> as basering when constructing a polyhedron from inequalities, you need to specify it for the constructor.
</p>
</blockquote>
<p>
Ok... fine.
</p>
Ticketgh-kliemThu, 29 Aug 2019 18:51:40 GMT
https://trac.sagemath.org/ticket/27973#comment:60
https://trac.sagemath.org/ticket/27973#comment:60
<p>
Is this good to go now?
</p>
TicketjipilabFri, 30 Aug 2019 12:41:06 GMTstatus, author changed; reviewer set
https://trac.sagemath.org/ticket/27973#comment:61
https://trac.sagemath.org/ticket/27973#comment:61
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
<li><strong>reviewer</strong>
set to <em>Jean-Philippe Labbé</em>
</li>
<li><strong>author</strong>
changed from <em>Laith Rastanawi</em> to <em>Laith Rastanawi, Jonathan Kliem</em>
</li>
</ul>
TicketvbraunThu, 05 Sep 2019 21:33:25 GMTstatus, branch changed; resolution set
https://trac.sagemath.org/ticket/27973#comment:62
https://trac.sagemath.org/ticket/27973#comment:62
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>closed</em>
</li>
<li><strong>resolution</strong>
set to <em>fixed</em>
</li>
<li><strong>branch</strong>
changed from <em>public/27973-new</em> to <em>38944ad77e0a7ca760e97fcef85f2b957fe83eba</em>
</li>
</ul>
Ticket