[PPL-devel] Question about PPL: Only one polyhedron-representation

[Roberto Bagnara]

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

-- 
Prof. Roberto Bagnara
Applied Formal Methods Laboratory
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bagnara at cs.unipr.it