[PPL-devel] How to do Powerset element normalization

[Pedro Vasconcelos]

[ Sorry about my last incomplete reply. Here it is in full ]

On Tue, 09 Nov 2004 21:50:57 +0100
Roberto Bagnara <bagnara at cs.unipr.it> wrote:

> By the way, we (the PPL developers) are more and more curious
> about these Haskell bindings we have read about in some recent
> messages to the mailing list.  It may come as a surprise to you,
> but we never saw them and we have not the slightest idea about
> how they look like.  Can you give us a pointer?

The bindings are just Haskell library code that calls the PPL C
interface functions. It also defines Haskell wrapper types for (pointers
to) the PPL data objects. So effectively the Haskell interface in built
on top of the C one and you get the same API as with C.

Axel Simon wrote the basic Haskell interface code and I got it from him.
He didn't made publicly available because he came across a bug he
couldn't resolve. It turned out to be of a memory allocation conflict
which I managed to get around it by linking the PPL with a private
version of libgmp. This is still a bit of a hack, so  I don't know if
Axel has made it available yet on his web page. For me, I'd much prefer
to use Haskell than C/C++ or Prolog, so that's incentive enough to get
it working...

> So, let us start with your question.  Premise number 1 is that I am
> not against providing `omega_reduce()' to the user of Polyhedra_Powerset.
> Premise number 2 is that I prefer to be extra-sure providing
> `omega_reduce()' to the user of Polyhedra_Powerset is the right thing
> to do.  The obvious question I have to ask you is: why would you want
> to have access to `omega_reduce()?  What is the effect you wish to
> obtain?  Afterall, one may say that a Polyhedra_Powerset and its
> omega-reduced counterparts have the same semantics. 

True, I should be more explict: I only need omega_reduce() before
converting constraints to a Haskell representation after a sequence of
polyhedral computations. The constraints should be simplified for pretty
printing and because they will eventually get replicated. I know I could
just leave them in the PPL world, but I prefer to use the PPL as a
"black box" solver and get an observable value out  (at least for the
time being). 

> 
> To make a parallel with a similar situation with the C_Polyhedron
> and NNC_Polyhedron classes, we do not provide a method `minimize()'
> to the user.  We rather ask the user to declare what is wanted by
> calling `miminized_constraints()' or `minimized_generators()' and
> keep polyhedra minimization as an internal business the user needs
> not be concerned about.  Up to now, this design choice has proved
> its value without showing any drawback.

Yes, but I could not find an analogous operation for Powersets. I am
using minimzed_constraints() for each powerset element, but (of course)
that doesn't eliminate redundant elements (for example: bottom elements).

> The method `pairwise_reduce()' does a different thing (please consult
> the documentation and complain if it does not provide enough information).
> And moreover, it is quite expensive.

Yes, I thought as much! 

Thanks for your thorough reply, 

Pedro Vasconcelos