Joseph S. Myers wrote:

On Sun, 3 Aug 2008, Richard Guenther wrote:

...

Sure. But modulo bugs there shouldn't be a difference in code-generation (for the PPL part at least), as it provides "basic math" like mpfr. Code generation could be affected by the version of Cloog though.

Thanks - this is useful information. If PPL's interface is such that there is a unique correct output for any inputs, like MPFR, then indeed we only need check the version is recent enough rather than requiring an exact version.

Dear All,

I think a little clarification is necessary. It is not strictly true that the PPL's interface is such that there is a unique correct output for any input. Let us start from generic convex polyhedra, which (as far as I can tell) is the only numerical abstraction used by cloog. There the point is that, given a convex polyhedron, there are many minimal constraint systems (i.e., not containing any redundant constraint) that describe it. No polyhedra library that I know uses strong normalization methods for constraints (like the Gram-Schmidt orthogonalization process) since they are costly and tend to produce very big coefficients. So the most that can be guaranteed is a minimal form (i.e., with the minimum number of individually-normalized constraints), but there is no guarantee to obtain, for the same polyhedron, the same set of constraints. However, if you stick to a particular PPL release, you can count on obtaining the same set of constraints on all architectures.

Other numerical abstractions implemented by the PPL, such as octagonal shapes, bounded-difference shapes and boxes using floating point coefficients, give rise to results that are not exactly reproducible. The only guarantee that the PPL provides is correctness; due to the nature of floating point computations any change of PPL version, compiler version, architecture, math library and so forth may give rise to different (but always correct) results.

Finally, the mixed integer programming solver integrated in the PPL optionally use floating point computations in order to implement the steepest-edge heuristics: in the presence of multiple optima you can get one or another depending on all that influences the execution of floating point computations. All the best,

Roberto