Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!cica!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!munnari.oz.au!murtoa.cs.mu.oz.au!ditmela!latcs1!mahler
From: mahler@latcs1.oz (Daniel Mahler)
Newsgroups: comp.lang.prolog
Subject: Re: Floating Point
Message-ID: <6688@latcs1.oz>
Date: 26 Oct 89 16:30:13 GMT
References: <2491@munnari.oz.au> <36169@srcsip.UUCP> <2524@munnari.oz.au>
Reply-To: mahler@latcs1.oz (Daniel Mahler)
Organization: Comp Sci, La Trobe Uni, Australia
Lines: 42


	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.
If you have done high school physics you know about the evils
of over representing accuracy by not stating error and including
to many significant digits.
The precision is not lost as the heavily numrical functions will
presumably be either system provided or interfaced in from another
language (if you thing prolog is better for numerical programs
then fortran or apl or ..., you deserve your troubles), so they would
be precise as can be. The point is to unify them as accurately as can
be.
	The problem is that floating point arithmetic is conceptually
incompatible with unification, only identical objects should unify
(be made one) and 3.141593 is not the same object as pi.
The only interpretation of floating unification I can think of
is equal to the known accuracy. Most of the time you should
be doing | X - Y | < error rather then unifying, but even then
you should not be using the last digit.
	A more prolog consistent approach if your application
does not require irrationals, is to use ratios of bignums
as in common lisp, provided you cancel out after every operation.
Otherwise any real compution in prolog should be done symbolycally
as much as possible, but if you have to use floats, go fuzzy.
Even apl, which is a numerical language, uses fuzzy equality
(though of course other numerical languages do not).
	None the less fuzzynes does introduce its own
problems. Non-transitivity is serious but can be handled
by testing all numbers against the first one though this
can get very tricky while backtracking.
If unification is implemented fuzzy though, other predicates must
be fuzzy also, especially (because it is realy unification)
equality and inequalities (a number is greater only
if it is significantly greater, and the same goes for ~= (!))

			Daniel

unification would be nice