Changes between Initial Version and Version 3 of Ticket #28506

09/16/19 15:47:34 (2 years ago)

I did both approaches. The approach that always takes the fraction is pushed into public/28506-bis.

I guess there are pros and cons of both methods. I think most important cons are:

  • try ... except might take more much more time (I assume it can theoretically compute almost everything)
  • try ... except is a bad approach, if there was ever a thing as a lazy polyhedron (but then again, its a bad idea to set up a lazy Polyhedron in ZZ from inequalities and don't check, whether this works)
  • always taking fraction field changes the behavior of the methods (and it looks awful for Minkowski decomposition)

New commits:

fa1a517added doctests that 28506 is fixed
e86ea8bfixed 28506 by trying fraction field at failure


  • Ticket #28506

    • Property Status changed from new to needs_review
    • Property Authors changed from to Jonathan Kliem
    • Property Summary changed from Direct sum of polyhedron is broken to Direct sum of polyhedron is broken, so is minkowski difference and face truncation
    • Property Branch changed from to public/28506
    • Property Commit changed from to e86ea8b2bbd1fdd017aa22a9318d3f08c3c3cfe6
  • Ticket #28506 – Description

    initial v3  
    66sage: t = s2.direct_sum(s3)
     9H-Polyhedra might have non-integral vertices and it is hard to tell from the H-Representation, whether this this is the case.
     11We fix `direct_sum`, `minkowski_difference` and `face_truncation` to try the quotient ring, if the given base ring does not work.