[PPL-devel] Confusion about "space dimension"

[Roberto Bagnara]

Now that the PPL is no longer limited to ordinary convex polyhedra
and many new abstractions are finding their way to the library,
I believe that the distinction between syntax and semantics
is fundamental.  According to this view, the PPL would support
a set of "syntactic objects" (variables, linear expressions,
constraints, congruences, generators, grid-generators, ...
and finite systems of such things) and a set of "semantic objects"
(polyhedra, grids, bounded-difference shapes, octagons, bounding
boxes, ..., powersets of the above, ..., linear programming problems,
...).

I think this distinction must be kept as clear as possible.
We are already doing it, to some extent, but the fact that
some syntactic objects are directly used in the implementation
of semantic objects has caused some of our syntactic objects to
expose some inner details of their role in the implementation
of semantic objects.  To clarify, this program

#include <ppl.hh>

using namespace Parma_Polyhedra_Library;
using namespace Parma_Polyhedra_Library::IO_Operators;
using namespace std;

int main() {
   Variable x(0);
   Variable y(1);
   Variable z(2);
   Linear_Expression e = x+y+z;
   cout << e << " has space dimension " << e.space_dimension() << endl;
   e -= z;
   cout << e << " has space dimension " << e.space_dimension() << endl;
   return 0;
}

prints

A + B + C has space dimension 3
A + B has space dimension 3

whereas it should print

A + B + C has space dimension 3
A + B has space dimension 2

The same sin is committed by Constraint, Generator and so forth.
I believe we should stick to one, unambiguous definition of
"space dimension" and be consistent with it throughout the library.
We know what "space dimension" is for a semantic object: it is
also clearly stated in the documentation.  We need to find a similar
definition that works for syntactic objects (such as the minimum space
dimension for which the object makes sense) or conclude that the notion of
"space dimension" should be reserved to semantic objects only
and find another name for this other concept.
Feedback is welcome on all these points.
Ciao,

     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