[PPL-devel] Re: Asking help using PPL's C interface

[Roberto Bagnara]

Hosung Song wrote:
 > Thank you very much for your prompt and kind reply. Shame on me. I knew
 > the existence of the directory, but I just glanced it and I didn't
 > thought it was a C interface example. Yeah, I didn't look into it so
 > far. I just tried that and compilation alone was not easy. After couple
 > of 'gcc lpenum.c', I found I needed GLPK library. Downloaded and
 > installed. Still 'make' or 'make all' or 'make lpenum' didn't work, so I
 > tried 'gcc -o lpenum lpenum.c -l...' and finally it took me to figure
 > out that I need about 5 -l flags like 'gcc -o lpenum lpenum.c -lglpk
 > -lppl_c -lppl -lgmpxx -lgmp'. It compiled and linked well, and I got the
 > same result as in 'expected'. I hope the compilation was easy and GLPK's
 > necessity was stated. Maybe they are all done in some place, and I may
 > be just lazy and impatient...

Dear Hosung,

no, the need for GLPK was not stated anywhere, but it is now.
However, if GLPK is installed, this is detected at configuration time,
after which `lpenum' is simply built using `make'.  Prompted by your
messages, we have added more information on how to use the C interface.
This will be included in release 0.6 of the library.  You can have a look
at the latest version of the file ppl_c.h.in available at

   http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/ppl/interfaces/C/ppl_c.h.in?cvsroot=ppl

 > It looks like using the C interface is a
 > little tedious than using the C++ interface. I wish I could use C++
 > library directly from my C program. I'll look into the lpenum example
 > for a while. Thanks again.

The C interface _is_ more tedious to program with.  This is a
consequence of C's somewhat limited expressivity with respect to C++.
Lack of overloading (both operator and function overloading) is
responsible for part of the bother.  Most importantly, it is the lack
of exceptions that makes programming with the C interface quite heavy
because (1) you need to explicitly check for errors and (2) the
function value has to encode (also) the status.  You should take the
functions of the C interface as an assembly language: they are
tedious, but you can do everything with them and, in particular, you
can write abstractions that are lighter to use and that suit your
application.

 > Regarding desired features, I'm wondering if you have any plan to
 > support machine integer types as coefficients. I'm just guessing that
 > using GMP can be quite time consuming. Of course, that can give us the
 > ability to describe arbitrarily large polyhedra, but I suppose it can be
 > also desirable to have faster library even with some restrictions.

Yes, we have a development branch where we are implementing support
for different kinds of coefficients.  We will soon have:

1) Unchecked machine integers.  Something that should never ever be used
    for real applications because without overflow detection the results
    are, of course, not reliable at all.  But something that is interesting
    to have in order to quantify the overhead of the real solutions.

2) Machine integers with overflow checking.  In case of overflow the
    application will know that something went wrong and can resort
    to a library incarnation with bigger/unlimited integers.

3) Unbounded integers with a specialized representation for small values,
    and a GMP representation for big values.  If done properly and with
    applications requiring mostly small integers, this should be both
    safe and competitive in performance with native machine integers.

I expect this work to be usable in a couple of months.

 > I checked out three libraries (PPL, new Polka, and IRISA one), and it
 > seemed PPL is the only one supporting dimension addition/deletion, and
 > best documented/packaged. The support of flexible dimensions is very
 > important to me because the model checker I'm working on should be able
 > to instantiate new analog variables as hybrid processes are instantiated
 > in the middle of system executions. The necessity of a polyhedron
 > library for my case is that we need to store values of analog variables
 > with polyhedra, which are time-abstracted representation of sets of
 > points in n-dimensional space R^n. Mostly I will just need
 > intersections, time-elapse, and equality check operations. Thanks again
 > and let me email you if I come up with desired features or improvements.

Good.  We look forward to your feedback.
All the best,

      Roberto

-- 
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bagnara at cs.unipr.it