On 10/25/2010 04:04 PM, Enea Zaffanella wrote:
Il 25/10/2010 11:35, Sebastian Junges ha scritto:
Dear PPL-developers,
We're currently considering to write a library making use of PPL.
The main problem is that for method investigations we would like to make use of only one representation a time for polyhedra. Is there an efficient way of using the existing PPL, in such a manner that we can choose whether a constraint- or generator-based representation of polyhedra is used.
No, currently there is no provision for such an option.
We know that most functions are only implemented for only one of the representations, and we would add functions needed for the other representation ourselves. Thus, as question remains if we can efficiently stop the polyhedra from being updated to consistency after a changing function is run.
On the one hand, the PPL library does not force a polyhedron to have both representations available.
On the other hand, most of the supported operations require that a specific one of the two representations is available as input. Hence, if that is not the case, the library will automatically perform the conversion between representations. Moreover, on exit, if keeping both representations is considered "cheap", then they will be kept. A few operators can work on either one of the two representations, so they never require a conversion.
I don't think there currently is a way to easily _and_ efficiently "drop" one of the two representations. The simple (but inefficient) way would be to construct a brand new polyhedron using one of the two representations as input. If generally helpful, we might consider adding such a "drop" operator ... but I would also like to hear the opinions of other developers in this respect.
Hi Sebastian,
we have the following item in our TODO list:
- Consider the addition of "constraint-only" methods (e.g., computing projections and upper bounds using the MIP solver).
I don't know if you are willing to tackle this, that is, adding the needed functions to the PPL so as to realize this point.
Alternatively, you could study the current implementation in order to understand under which circumstances the representation you don't want is computed and supply the needed functions externally. And we can easily add the "drop" operation suggested by Enea. Of course this is suboptimal, because your code would depend on contingent implementation details of the PPL. All the best,
Roberto