Polyhedron -- make constructions respect backend

[Jonathan Kliem]

At the moment the backend setting is lost, when constructing a pyramid of a Polyhedron.

Same holds for all other constructions.

I think that all constructions should respect the backend of self. I intend to create tickets (one by one) for each construction in Polyhedron_base (that gives a new Polyhedron).

Any thoughts on this?

Also I think the base ring should be respected as well (as is done in Polyhedron.translation).

At the moment it can happen, that the base ring shrinks, when constructing a pyramid for example

(if the user forced base ring QQ, there might have been good reason for doing so, and I would say it is not nice, if one has to change base ring again along the way).

[Vincent Delecroix]

To my mind:

* backend and base ring should be preserved by default. Of course
it should make sense: a translation by sqrt(2) would break the
base ring QQ.

* no need to create one ticket for each method if this is mostly
the same action to be done for each of them. If some method needs
special care or give rise to discussions, a specific ticket could
be open.

Vincent

[Jonathan Kliem]

Actually, base ring is preserved already. Just assumed it gets lost as well.

The backend is lost though.

Something as

sage: polytopes.dodecahedron(backend='normaliz').pyramid()

will create a polyhedron with backend 'field'.

[jplab]

Hi Jonathan,

Le lundi 3 juin 2019 23:31:29 UTC+2, vdelecroix a écrit :

To my mind:

  * backend and base ring should be preserved by default. Of course
    it should make sense: a translation by sqrt(2) would break the
    base ring QQ.

+1

  * no need to create one ticket for each method if this is mostly
    the same action to be done for each of them. If some method needs
    special care or give rise to discussions, a specific ticket could
    be open.

+1

Le 03/06/2019 à 23:25, 'Jonathan Kliem' via sage-devel a écrit :
> At the moment the backend setting is lost, when constructing a pyramid of a
> Polyhedron.
>
> Same holds for all other constructions.

If you are ready to go through the construction to make them consistent with the above convention: great!

> Any thoughts on this?
>
> Also I think the base ring should be respected as well (as is done in
> Polyhedron.translation).
> At the moment it can happen, that the base ring shrinks, when constructing
> a pyramid for example
> (if the user forced base ring QQ, there might have been good reason for
> doing so, and I would say it is not nice, if one has to change base ring
> again along the way).

It is hard to make sense of "If the user forced base ring QQ" after the object got created.

How should we know if that keyword was given when looking at the object?

The reason I ask this question is because I do not believe that the usage of the keyword

"base_ring" is "to force the base ring used", but rather to help the constructor to build the

desired object in a specific base ring: the input is converted in that base ring (if possible)

once things are constructed. Then, as Vincent mentioned, and I agree, the base ring

should be kept as long as it is possible.

On the other hand, a user "forcing QQ"  can be thought as a peculiar thing to do. Every

rational polyhedron has an integer H-representation, so if one looks at the H-representation,

QQ is not necessary to write the H-representation. The distinction comes from the

V-representation and has consequences on the related objects (Ehrhart quasi-polynomial

vs Ehrhart polynomial and any method that makes use of integer arithmetic...). So, yes

there should be a distinction between the two base rings ZZ and QQ. That said, I believe that internally,

it should always try to take the "simplest" base ring possible. If the user then wants a

different ring, then Sage will give the object back in that one, but may do computations with a

different ring. So now again, does "forcing a base ring" makes sense?

That said, as explained in the tutorial

http://doc.sagemath.org/html/en/thematic_tutorials/geometry/polyhedra_tutorial.html

A clean way to work with polyhedron is to have the objects already be in a common base ring already.

If this is not possible and one gives different types in the input, then it will go on and figure out a

proper base ring. But, since this might take a while, the keyword "base ring" helps in this regards.

So, one should be careful in using this keyword... For example, after #25097 is merged, this will become possible:

sage: sqrt_2s = sqrt(2)
sage: cbrt_2s = 2^(1/3)
sage: P1 = Polyhedron(vertices = [[sqrt_2s, 0], [0, cbrt_2s]]);P1
Traceback (most recent call last):
...
ValueError: no appropriate backend for computations with Symbolic Ring

sage: P2 = Polyhedron(vertices = [[sqrt_2s, 0], [0, cbrt_2s]],backend='normaliz');P2
A 1-dimensional polyhedron in (Symbolic Ring)^2 defined as the convex hull of 2 vertices

sage: Polyhedron(vertices = [[sqrt_2s, 0], [0, cbrt_2s]],backend='field')
Traceback (most recent call last):
...
ValueError: the 'field' backend for polyhedron can not be used with non-exact fields

The object P2's base ring is the Symbolic Ring, but the computations are done in the normaliz field accessible with the method `_normaliz_field`. 

J-P

[Jonathan Kliem]

I have started #27926.

I think I leave the base ring business as it is for now. I belive it is taken care of in many (if not all) places, where the base ring of the vertices might differ.

good