Opened 2 years ago

# Implement wedge over a face of Polyhedron — at Version 38

Reported by: Owned by: jipilab major sage-8.9 geometry polytopes, days100, wedge, facet jipilab, gh-LaisRast, gh-kliem Laith Rastanawi N/A public/27973 6ba559456a3770c5517956db2d7ae1ed44a8d717

The wedge over a facet F of a polytope P is defined as:

(P \times \mathbb{R}) \cap \{a^\top x +|x_{d+1}| \leq b\}

where F is a facet defined by a^\top x leq b.

It has dimension d+1, m+1 facets, and 2n-n_F vertices, if F has n_F vertices. More generally, the wedge construction can be performed (defined by the same formula) for a face F.

### comment:1 Changed 2 years ago by gh-kliem

• Description modified (diff)

### comment:2 Changed 2 years ago by embray

• Milestone sage-8.8 deleted

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

### comment:4 Changed 2 years ago by gh-LaisRast

• Authors set to Laith Rastanawi
• Branch set to public/27973
• Commit set to 45bd3123afcafe3ef142e19bbb04f0d6ebda849e
• Status changed from new to needs_info

New commits:

 ​d0be5c6 add wedge method in Polyhedron class in base.py ​45bd312 NotImplementedError -> ValueError

### comment:5 Changed 2 years ago by gh-LaisRast

• Status changed from needs_info to needs_review

### comment:6 Changed 2 years ago by jipilab

Hi,

• In the docstring, it usually starts with 1 sentence, and empty line and then further information about the method.
• 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".
• The doctests are not using the function as a method.
• Replace the backtick by single quotes in the error messages.
• L = Polyhedron(rays=[[1],[-1]]) could be Polyhedron(lines=[[1]])
• I would write F_Hrep = list(F_Hrep) after the for loop and replace in the creation of the polytope.
• 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.

### comment:7 follow-up: ↓ 9 Changed 2 years ago by jipilab

• Status changed from needs_review to needs_work

### comment:8 Changed 2 years ago by git

• Commit changed from 45bd3123afcafe3ef142e19bbb04f0d6ebda849e to 049e27d49147ebf269a0d3267ae0dd32c1637e42

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

 ​049e27d more examples and fix docstring

### comment:9 in reply to: ↑ 7 Changed 2 years ago by gh-LaisRast

• Status changed from needs_work to needs_review

Thanks. Done.

### comment:10 Changed 2 years ago by jipilab

Seems like there are tab character in reference/index.rst There seems to be many errors in the bot too...

### comment:11 Changed 2 years ago by git

• Commit changed from 049e27d49147ebf269a0d3267ae0dd32c1637e42 to 193e06bd91b8cd16d8ec796fcae0ac91ee8b592a

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

 ​193e06b tabs to spaces

### comment:12 follow-up: ↓ 15 Changed 2 years ago by gh-kliem

The description of the ticket is still only about facets.

### comment:13 Changed 2 years ago by gh-kliem

• Status changed from needs_review to needs_work

Please preserve the backend and base ring as in #27926.

### comment:14 follow-up: ↓ 16 Changed 2 years ago by gh-kliem

Actually, I think the backend might be preserved. (product and intersection might behave this way).

However, in the intermediate steps you don't preserve the backend. This might cause issues with algebraic polyhedra.

Last edited 2 years ago by gh-kliem (previous) (diff)

### comment:15 in reply to: ↑ 12 Changed 2 years ago by jipilab

The description of the ticket is still only about facets.

Nope. See last sentence of the description.

### comment:16 in reply to: ↑ 14 ; follow-up: ↓ 18 Changed 2 years ago by gh-LaisRast

Actually, I think the backend might be preserved. (product and intersection might behave this way).

However, in the intermediate steps you don't preserve the backend. This might cause issues with algebraic polyhedra.

The backend and the basering are preserved as long as the value of width belongs to the basering of self. This is the case when width takes the default value. Otherwise, we have the following behavior

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


which I think is an acceptable behavior.

### comment:17 Changed 2 years ago by git

• Commit changed from 193e06bd91b8cd16d8ec796fcae0ac91ee8b592a to 417bfac337f17e93494d8f31b9031f9311cee423

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

 ​417bfac add tests to check backend and basering

### comment:18 in reply to: ↑ 16 ; follow-ups: ↓ 19 ↓ 21 Changed 2 years ago by gh-kliem

The examples you gave are not meaningful. ppl and cdd are the standard backends for the given ring.

What about normaliz with base ring ZZ and width 5/2 (even worse 4/2)? (I suspect backend will not be preserved).

What about the examples of #25097. Do they work?

(Sorry, still can't test it myself).

Actually, I think the backend might be preserved. (product and intersection might behave this way).

However, in the intermediate steps you don't preserve the backend. This might cause issues with algebraic polyhedra.

The backend and the basering are preserved as long as the value of width belongs to the basering of self. This is the case when width takes the default value. Otherwise, we have the following behavior

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


which I think is an acceptable behavior.

### comment:19 in reply to: ↑ 18 ; follow-up: ↓ 20 Changed 2 years ago by gh-LaisRast

What about normaliz with base ring ZZ and width 5/2 (even worse 4/2)? (I suspect backend will not be preserved).

What about the examples of #25097. Do they work?

(Sorry, still can't test it myself).

The polyhedron H 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 W2 below):

-    def wedge(self, face, width=1):
+    def wedge(self, face, width=None):
r"""
Return the wedge over a face of the polytope self.

@@ -4205,6 +4205,10 @@ class Polyhedron_base(Element):
sage: P.wedge(P.faces(2)[0], width=RDF(1)).base_ring()
Real Double Field
"""
+        if width is None:
+            width = ZZ.one()
+
if not self.is_compact():
raise ValueError("polyhedron 'self' must be a polytope")

@@ -4223,7 +4227,11 @@ class Polyhedron_base(Element):

L = Polyhedron(lines=[[1]])
Q = self.product(L)
-        H = Polyhedron(ieqs=[F_Hrep + [width], F_Hrep + [-width]])
+
+        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])
return Q.intersection(H)



Some examples:

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


W2 has vertices with integer coordinates

### comment:20 in reply to: ↑ 19 ; follow-up: ↓ 25 Changed 2 years ago by gh-kliem

Is this ZZ.one() really needed? Base extend should work recognize 1 as well.

Can you add base_ring=self.base_ring() and same for backend to initialization of L. (Setting up the correct base ring right away, avoids coercion for the product to my understanding.)

What about normaliz with base ring ZZ and width 5/2 (even worse 4/2)? (I suspect backend will not be preserved).

What about the examples of #25097. Do they work?

(Sorry, still can't test it myself).

The polyhedron H 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 W2 below):

-    def wedge(self, face, width=1):
+    def wedge(self, face, width=None):
r"""
Return the wedge over a face of the polytope self.

@@ -4205,6 +4205,10 @@ class Polyhedron_base(Element):
sage: P.wedge(P.faces(2)[0], width=RDF(1)).base_ring()
Real Double Field
"""
+        if width is None:
+            width = ZZ.one()
+
if not self.is_compact():
raise ValueError("polyhedron 'self' must be a polytope")

@@ -4223,7 +4227,11 @@ class Polyhedron_base(Element):

L = Polyhedron(lines=[[1]])
Q = self.product(L)
-        H = Polyhedron(ieqs=[F_Hrep + [width], F_Hrep + [-width]])
+
+        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])
return Q.intersection(H)



Some examples:

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


W2 has vertices with integer coordinates

### comment:21 in reply to: ↑ 18 ; follow-up: ↓ 22 Changed 2 years ago by jipilab

What about normaliz with base ring ZZ and width 5/2 (even worse 4/2)? (I suspect backend will not be preserved).

A note: in Sage 4/2 is rational:

sage: type(4/2)
<class 'sage.rings.rational.Rational'>


and it should be like that, not to create nightmares.

Hence, taking width=4/2, the expected behavior is really to change the base ring to rational numbers.

In Sage dividing two Integers yields an element in the FractionField?, i.e. the rationals. It is the users responsibility to know these things. Just like 2.0 is not an integer.

That said, it is completely fine to have base_ring=QQ but integral vertices. The goal of base ring is not to steadily represent the smallest ring in which the vertices lay in.

### comment:22 in reply to: ↑ 21 ; follow-up: ↓ 23 Changed 2 years ago by gh-kliem

I was aware of 4/2 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 width=2.0 the backend will change to cdd, which I would consider the expected behavior.)

It's just annoying when you want to use normaliz and every operation ignores your preference and you have to change backend over and over (and even worse calculations might take longer time with ppl, which you decided not to use in the first place).

What about normaliz with base ring ZZ and width 5/2 (even worse 4/2)? (I suspect backend will not be preserved).

A note: in Sage 4/2 is rational:

sage: type(4/2) <class 'sage.rings.rational.Rational'> }}}

and it should be like that, not to create nightmares.

Hence, taking width=4/2, the expected behavior is really to change the base ring to rational numbers.

In Sage dividing two Integers yields an element in the FractionField?, i.e. the rationals. It is the users responsibility to know these things. Just like 2.0 is not an integer.

That said, it is completely fine to have base_ring=QQ but integral vertices. The goal of base ring is not to steadily represent the smallest ring in which the vertices lay in.

### comment:23 in reply to: ↑ 22 Changed 2 years ago by jipilab

I was aware of 4/2 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 width=2.0 the backend will change to cdd, which I would consider the expected behavior.)

It's just annoying when you want to use normaliz and every operation ignores your preference and you have to change backend over and over (and even worse calculations might take longer time with ppl, which you decided not to use in the first place).

What about normaliz with base ring ZZ and width 5/2 (even worse 4/2)? (I suspect backend will not be preserved).

A note: in Sage 4/2 is rational:

sage: type(4/2) <class 'sage.rings.rational.Rational'> }}}

and it should be like that, not to create nightmares.

Hence, taking width=4/2, the expected behavior is really to change the base ring to rational numbers.

In Sage dividing two Integers yields an element in the FractionField?, i.e. the rationals. It is the users responsibility to know these things. Just like 2.0 is not an integer.

That said, it is completely fine to have base_ring=QQ but integral vertices. The goal of base ring is not to steadily represent the smallest ring in which the vertices lay in.

Of course, of course. The only thing to do is to carry the backend to the wedge, no big deal...

### comment:24 Changed 2 years ago by git

• Commit changed from 417bfac337f17e93494d8f31b9031f9311cee423 to 7653fb8d21fc31d7ab34ff2c1c6da050934adef9

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

 ​00f2253 polyhedron H now preserves backend now ​09597bd backend should be preserved now ​7653fb8 Now should work if width is in RDF

### comment:25 in reply to: ↑ 20 ; follow-up: ↓ 27 Changed 2 years ago by gh-LaisRast

Base extend should work recognize 1 as well.

Not anymore after the last commit I did. ZZ.one() is really needed now. The width should have a base_ringmethod in order for the wedge to work.

Can you add base_ring=self.base_ring() and same for backend to initialization of L. (Setting up the correct base ring right away, avoids coercion for the product to my understanding.)

This might produce problems due to the following behavior:

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


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

New commits:

 ​00f2253 polyhedron H now preserves backend now ​09597bd backend should be preserved now ​7653fb8 Now should work if width is in RDF

### comment:26 Changed 2 years ago by gh-LaisRast

• Status changed from needs_work to needs_review

### comment:27 in reply to: ↑ 25 Changed 2 years ago by gh-kliem

Base extend should work recognize 1 as well.

Not anymore after the last commit I did. ZZ.one() is really needed now. The width should have a base_ringmethod in order for the wedge to work.

Can you add base_ring=self.base_ring() and same for backend to initialization of L. (Setting up the correct base ring right away, avoids coercion for the product to my understanding.)

This might produce problems due to the following behavior:

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


I think that's a bug.

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

New commits:

 ​00f2253 polyhedron H now preserves backend now ​09597bd backend should be preserved now ​7653fb8 Now should work if width is in RDF

### comment:28 follow-up: ↓ 29 Changed 2 years ago by gh-kliem

• Status changed from needs_review to needs_work

Most importantly the normaliz tests should be marked optional as pynormaliz cannot be assumed to be installed. Alternatively, you can switch to backend field for the tests, this demonstrates as well that the backend is preserved.

The current code does not work with width a python integer ect. How about parent = self.parent().base_extend(width/1, …, I believe this works as well. Then a default width=1 would be fine as well. As of #27926 parent.base_extend works with elements of rings and numbers that can be interpreted as such.

Last edited 2 years ago by gh-kliem (previous) (diff)

### comment:29 in reply to: ↑ 28 ; follow-ups: ↓ 31 ↓ 32 Changed 2 years ago by gh-LaisRast

Most importantly the normaliz tests should be marked optional as pynormaliz cannot be assumed to be installed. Alternatively, you can switch to backend field for the tests, this demonstrates as well that the backend is preserved.

I switched to field.

The current code does not work with width a python integer ect. How about parent = self.parent().base_extend(width/1, …, I believe this works as well. Then a default width=1 would be fine as well. As of #27926 parent.base_extend works with elements of rings and numbers that can be interpreted as such.

In python3 (resp. python2), x = 1/1; type(x) gives <class 'float'> (resp. <type 'int'>), which does not have a .base_ring(). I need .base_ring() so I can find its .fraction_field().

### comment:30 Changed 2 years ago by git

• Commit changed from 7653fb8d21fc31d7ab34ff2c1c6da050934adef9 to c77c1af1ff8732512b3cd25fe6bdc4a138041c34

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

 ​c77c1af normaliz -> field in tests

### comment:31 in reply to: ↑ 29 ; follow-up: ↓ 33 Changed 2 years ago by gh-LaisRast

• Status changed from needs_work to needs_review

Most importantly the normaliz tests should be marked optional as pynormaliz cannot be assumed to be installed. Alternatively, you can switch to backend field for the tests, this demonstrates as well that the backend is preserved.

I switched to field.

The current code does not work with width a python integer ect. How about parent = self.parent().base_extend(width/1, …, I believe this works as well. Then a default width=1 would be fine as well. As of #27926 parent.base_extend works with elements of rings and numbers that can be interpreted as such.

In python3 (resp. python2), x = 1/1; type(x) gives <class 'float'> (resp. <type 'int'>), which does not have a .base_ring(). I need .base_ring() so I can find its .fraction_field().

Having ZZ.one() as default instead of python 1 solves the problem for the default value. If the value of width is not the default value, then it is a sage ring element. This solves the problem for non-default values.

### comment:32 in reply to: ↑ 29 Changed 2 years ago by gh-kliem

Most importantly the normaliz tests should be marked optional as pynormaliz cannot be assumed to be installed. Alternatively, you can switch to backend field for the tests, this demonstrates as well that the backend is preserved.

I switched to field.

The current code does not work with width a python integer ect. How about parent = self.parent().base_extend(width/1, …, I believe this works as well. Then a default width=1 would be fine as well. As of #27926 parent.base_extend works with elements of rings and numbers that can be interpreted as such.

In python3 (resp. python2), x = 1/1; type(x) gives <class 'float'> (resp. <type 'int'>), which does not have a .base_ring(). I need .base_ring() so I can find its .fraction_field().

parent._coerce_base_ring(1/1) gives rational field, which tells me that base extend works fine. Don't worry about passing a ring to Polyhedra.base_extend. Probably you should pass 1/width as argument base_ring:

-        parent = self.parent().base_extend(width.base_ring().fraction_field(),\
+        parent = self.parent().base_extend(1/width,\
ambient_dim=self.ambient_dim()+1)


This extends the ring of parent, such that 1/width is an element. There is a number of occasions, where I used base_extend this way to have polyhedral operations respect the base ring.

### comment:33 in reply to: ↑ 31 ; follow-up: ↓ 36 Changed 2 years ago by gh-kliem

Most importantly the normaliz tests should be marked optional as pynormaliz cannot be assumed to be installed. Alternatively, you can switch to backend field for the tests, this demonstrates as well that the backend is preserved.

I switched to field.

The current code does not work with width a python integer ect. How about parent = self.parent().base_extend(width/1, …, I believe this works as well. Then a default width=1 would be fine as well. As of #27926 parent.base_extend works with elements of rings and numbers that can be interpreted as such.

In python3 (resp. python2), x = 1/1; type(x) gives <class 'float'> (resp. <type 'int'>), which does not have a .base_ring(). I need .base_ring() so I can find its .fraction_field().

Having ZZ.one() as default instead of python 1 solves the problem for the default value. If the value of width is not the default value, then it is a sage ring element. This solves the problem for non-default values.

No. If you write a python script that uses this method, you will have to import Integer from sage as well to be able to pass width. Something as 1l or 1L or float(0.9) should work as well.

Actually you need to use ZZ.one()/width (not 1/width), which should do the trick. Sorry about the confusion. Alternatively, you find a method to map width to a sage ring element and then still do the fraction field.

### comment:34 Changed 2 years ago by gh-kliem

• Status changed from needs_review to needs_work

Please allow python integers (and floats) as input for width.

### comment:35 Changed 2 years ago by git

• Commit changed from c77c1af1ff8732512b3cd25fe6bdc4a138041c34 to ccce5f2c2fc9c63d307e799572fcce581079a569

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

 ​ccce5f2 python ints and floats can be used for width

### comment:36 in reply to: ↑ 33 Changed 2 years ago by gh-LaisRast

• Status changed from needs_work to needs_review

Most importantly the normaliz tests should be marked optional as pynormaliz cannot be assumed to be installed. Alternatively, you can switch to backend field for the tests, this demonstrates as well that the backend is preserved.

I switched to field.

The current code does not work with width a python integer ect. How about parent = self.parent().base_extend(width/1, …, I believe this works as well. Then a default width=1 would be fine as well. As of #27926 parent.base_extend works with elements of rings and numbers that can be interpreted as such.

In python3 (resp. python2), x = 1/1; type(x) gives <class 'float'> (resp. <type 'int'>), which does not have a .base_ring(). I need .base_ring() so I can find its .fraction_field().

Having ZZ.one() as default instead of python 1 solves the problem for the default value. If the value of width is not the default value, then it is a sage ring element. This solves the problem for non-default values.

No. If you write a python script that uses this method, you will have to import Integer from sage as well to be able to pass width. Something as 1l or 1L or float(0.9) should work as well.

Actually you need to use ZZ.one()/width (not 1/width), which should do the trick. Sorry about the confusion. Alternatively, you find a method to map width to a sage ring element and then still do the fraction field.

This is actually a good trick to deal with python numbers.

### comment:37 Changed 2 years ago by git

• Commit changed from ccce5f2c2fc9c63d307e799572fcce581079a569 to 6ba559456a3770c5517956db2d7ae1ed44a8d717

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

 ​6ba5594 width.base_ring().fraction_field() -> ZZ.one()/width

### comment:38 Changed 2 years ago by gh-LaisRast

• Description modified (diff)
Note: See TracTickets for help on using tickets.