🚀 go-pugleaf

In article <6688@latcs1.oz> mahler@latcs1.oz (Daniel Mahler) writes:
>
>	Having both kinds of real unification is naturally preferable if
>you have the computational resources (remember the discussion on swapping
>and threaded code last year). But if I had to choose I'd go fuzzy.
>The reason is that the least significant digit(s) of reals are wildly
>inaccurate. The reason they are there is to include them in the
>calculations so that the digits before them are accurate.

The source of the lack of precision in floating point is the bounded
size of flating point and the concomitant lack of precision in the results
of arithmetic operations. This has nothing to do with unification. Prolog
works with representations, sometimes approximate, of various objects.
Unification checks the identity of those representations, not the possible
equality of the underlying objects (thus unification in Prolog will not
try to figure out the intended interpretations of function symbols and
therefore will not unify +(A,+(B,C)) with +(+(A,B),C) where +'s intended
interpretation is integer addition, even though the intended interpretation
of those two expressions is the same).

The best developed theoretically justified paradigm for going beyond
syntactic unification (formal equality) in Prolog is the CLP framework.
Even CLP(R), however, is approximate in the sense that numeric precision
is ignored. Ideally, one might want to move to a CLP instance based on
interval arithmetic, in which precision has proper object-level representation
and semantics. BNR-Prolog, developed at Bell Northern Research by Andre
Vellino and others, even though not based on the CLP framework, includes
an interesting form of interval arithmetic (I'm not qualified to judge
its theoretical soundness or praticality, though, not being a numerical
analyst).

To recap: please leave formal identity (syntactic unification) alone.
The correct handling of domains such as the real numbers for which the
result of an operation on machine-representable elements might not be
exactly representable is a subtle problem, in which theoretically naive
solutions can do more harm than good. I burned my fingers once when, at the
request of users, I made the supperficially innocent choice of letting
C-Prolog automatically convert to integer any floating point number
that could have an integer representation (thereby ignoring the possibility
that the floating point number was actually an approximation to a non-integer
real number). Never again will I trust intuitions when dealing with
approximate representations!

Fernando Pereira
2D-447, AT&T Bell Laboratories
600 Mountain Ave, Murray Hill, NJ 07974
pereira@research.att.com