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 -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/69d9c711-f53f-48dc-9895-e98c1173fa17%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
