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.
Am Dienstag, 4. Juni 2019 11:20:07 UTC+2 schrieb 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. > good > 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/621e22a5-2ed3-4e40-8b28-4575700b516a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
