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?cvsroo...
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