February 2004 - PPL-devel - BUGSENG Mailman

ppl/interfaces/OCaml Makefile.am
by Roberto Bagnara 05 Feb '04

05 Feb '04

CVSROOT: /cvs/ppl Module name: ppl Changes by: roberto(a)cs.unipr.it 2004-02-05 15:46:45 Modified files: interfaces/OCaml: Makefile.am Log message: Add `-I../C' to libppl_ocaml_c_la_CPPFLAGS. Patches: http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/ppl/interfaces/OCaml/Makefile.am.…

1 0

ppl/interfaces/C ppl_c.cc ppl_c.h.in
by Roberto Bagnara 05 Feb '04

05 Feb '04

CVSROOT: /cvs/ppl Module name: ppl Changes by: roberto(a)cs.unipr.it 2004-02-05 14:52:42 Modified files: interfaces/C : ppl_c.cc ppl_c.h.in Log message: Documentation improvements. Patches: http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/ppl/interfaces/C/ppl_c.cc.diff?cv… http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/ppl/interfaces/C/ppl_c.h.in.diff?…

1 0

ppl/doc user-browse.doxyconf-latex.in user-pri ...
by Roberto Bagnara 05 Feb '04

05 Feb '04

CVSROOT: /cvs/ppl Module name: ppl Changes by: roberto(a)cs.unipr.it 2004-02-05 14:49:29 Modified files: doc : user-browse.doxyconf-latex.in user-print.doxyconf-latex.in user.doxyconf-html.in Log message: Add PPL_DECLARE_PRINT_FUNCTIONS to EXPAND_AS_DEFINED. Patches: http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/ppl/doc/user-browse.doxyconf-late… http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/ppl/doc/user-print.doxyconf-latex… http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/ppl/doc/user.doxyconf-html.in.dif…

1 0

ppl/interfaces/C ppl_c.h.in
by Roberto Bagnara 05 Feb '04

05 Feb '04

CVSROOT: /cvs/ppl Module name: ppl Changes by: roberto(a)cs.unipr.it 2004-02-05 14:23:08 Modified files: interfaces/C : ppl_c.h.in Log message: Make sure not to leave unnecessary preprocessor symbols behind. Patches: http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/ppl/interfaces/C/ppl_c.h.in.diff?…

1 0

ppl/interfaces/C ppl_c.cc ppl_c.h.in
by Roberto Bagnara 05 Feb '04

05 Feb '04

CVSROOT: /cvs/ppl Module name: ppl Changes by: roberto(a)cs.unipr.it 2004-02-05 14:18:50 Modified files: interfaces/C : ppl_c.cc ppl_c.h.in Log message: A first, tentative implementation of the new print functions. New error codes PPL_STDIO_ERROR and PPL_ARITHMETIC_OVERFLOW. Patches: http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/ppl/interfaces/C/ppl_c.cc.diff?cv… http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/ppl/interfaces/C/ppl_c.h.in.diff?…

1 0

ppl/interfaces/C ppl_c.h.in
by Roberto Bagnara 05 Feb '04

05 Feb '04

CVSROOT: /cvs/ppl Module name: ppl Changes by: roberto(a)cs.unipr.it 2004-02-05 09:30:40 Modified files: interfaces/C : ppl_c.h.in Log message: Added a kludge to make the documentation on how to use the C interface easier to find. Patches: http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/ppl/interfaces/C/ppl_c.h.in.diff?…

1 0

[Fwd: Re: Asking help using PPL's C interface]
by Roberto Bagnara 05 Feb '04

05 Feb '04

-------- Original Message -------- Subject: Re: Asking help using PPL's C interface Date: Wed, 04 Feb 2004 21:14:42 -0500 From: Hosung Song <hosungs(a)umich.edu> To: Roberto Bagnara <bagnara(a)cs.unipr.it> References: <4019F848.2010809(a)umich.edu> <4019FF57.8070707(a)cs.unipr.it> <401AA534.5020306(a)umich.edu> <40218430.1060308(a)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?cvsro… > > > 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@cs.unipr.it -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it

1 0

Re: Asking help using PPL's C interface
by Roberto Bagnara 05 Feb '04

05 Feb '04

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?cvsro… > 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@cs.unipr.it

1 0

ppl/interfaces/C ppl_c.h.in
by Roberto Bagnara 04 Feb '04

04 Feb '04

CVSROOT: /cvs/ppl Module name: ppl Changes by: roberto(a)cs.unipr.it 2004-02-04 18:47:11 Modified files: interfaces/C : ppl_c.h.in Log message: A couple of corrections to the usage instructions. Patches: http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/ppl/interfaces/C/ppl_c.h.in.diff?…

1 0

ppl/interfaces/C ppl_c.h.in
by Patricia Hill 04 Feb '04

04 Feb '04

CVSROOT: /cvs/ppl Module name: ppl Changes by: hill(a)cs.unipr.it 2004-02-04 18:25:10 Modified files: interfaces/C : ppl_c.h.in Log message: Corrections to the explanation on using the C interface done. Patches: http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/ppl/interfaces/C/ppl_c.h.in.diff?…

1 0