[comp.lang.prolog] Against fuzzy unification

ok@aucsv.UUCP (Richard Okeefe) (03/03/89)

I haven't seen anything at all in comp.lang.prolog since the question
about IC-Prolog.  What's happened?

Just to get discussion flowing again (in case it had stopped),
or to show that I am still alive (in case the it's this end at fault):

Two Prolog systems that I know of offer some form of "fuzzy
unification" where floating-point numbers which are not identical may
none-the-less be allowed to unify:  IBM's VM/PROLOG and a recent
version of SB-Prolog.

This is a lousy idea from a logic programming point of view, but it has
a certain naive appeal.  What is not sufficiently realised is that it is
a bad idea from a numerical analysis point of view.

If you want to write portable numerical software, there is essentially
only one game in town, Brown's "model numbers" system.  (The paper
appeared in ACM TOMS, I think it was in 1979 but it might have been in
1980.  It's the idea behind ADA floating-point.)  The idea is that you
distinguish a special subset of the machine's floating-point numbers
called the MODEL numbers (essentially the numbers where the machine's
arithmetic behaves itself).  The model numbers of a particular machine
are 0 U { +/- f x b**e | f is a fraction with p base-b digits, b >= 2,
and emin <= e <= emax}.  The parameters of a machine's model arithmetic
are p, b, emin, and emax.  These parameters are typically related to
the parameters of the machine's hardware arithmetic, but _penalties_
may be charged (emin may be raised, emax lowered, p reduced) to ensure
that the arithmetic satisfies the axioms in Brown's paper.  The axioms
include axioms for comparison.

The effect of including a comparison tolerance in unification is
TO REDUCE THE EFFECTIVE NUMBER OF TRUSTWORTHY DIGITS.  That is, if a
Prolog implementation uses fuzzy unification, the model parameters
must be set so that epsilon (defined in Brown's paper) is greater
than the comparison tolerance, which means that p is dramatically
reduced.  In effect, a comparison tolerance is a licence to the
compiler to introduce errors of up to that amount.

The bottom line, then, is that anyone designing a Prolog system to
support floating-point computation MAY provide fuzzy comparisons
(see Knuth Vol 2 for suitable definitions) IN ADDITION to the
"standard" =:= < > set but should leave the standard set and unification
crisp.