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

[Roberto Bagnara]

-------- Original Message --------
Subject: Re: Asking help using PPL's C interface
Date: Wed, 04 Feb 2004 21:14:42 -0500
From: Hosung Song <hosungs at umich.edu>
To: Roberto Bagnara <bagnara at cs.unipr.it>
References: <4019F848.2010809 at umich.edu> <4019FF57.8070707 at cs.unipr.it> <401AA534.5020306 at umich.edu> <40218430.1060308 at cs.unipr.it>

Thank you very much for your detailed kind response, and your update in
ppl_c.h! Also I look forward to the new version 0.6. In fact, after you
told me about lpenum, I played with it for a while, and I just applied
that to my project very easily. Now my hybrid system simulator can do
all sort of required polyhedra processing stuff. And I added some print
functions (I emailed about that to ppl-devel list), and I should tell
you that it is great pleasure to see the processed polyhedra as printed
constraints! Thanks again. I really appreciate your library and
kindness.

Best,

Hosung

Roberto Bagnara wrote:
> 
> 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


-- 
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