Newsgroups: comp.lang.prolog
Path: cantaloupe.srv.cs.cmu.edu!europa.chnt.gtegsc.com!news.mathworks.com!news.duke.edu!agate!library.ucla.edu!csulb.edu!csus.edu!netcom.com!ludemann
From: ludemann@netcom.com (Peter Ludemann)
Subject: Re: complexity of ==/2
Message-ID: <ludemannDCwBMv.E2q@netcom.com>
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
References: <LUDAESCH.95Jul24144618@malta.informatik.uni-freiburg.de>
Date: Sun, 6 Aug 1995 15:42:31 GMT
Lines: 30
Sender: ludemann@netcom12.netcom.com

In article <LUDAESCH.95Jul24144618@malta.informatik.uni-freiburg.de>,
Bertram Ludaescher <ludaesch@Informatik.Uni-Freiburg.DE> wrote:
>
>
>Q1: Given two *ground* terms T1, T2, such that T1=T2 is true, where
>=/2 is the unify predicate.  Does this imply that T1==T2?

Yes.

Actually, the conditions can be slightly weaker, replacing *ground* by
*sufficiently ground* (exercise for the student: can you give a
rigorous definition of "sufficiently ground").

>Q2: How expensive is ==/2 ? Does it compare subterms recursively by
>==/2 or does it a 'pointer comparison' on the top level?

Recursively.  The exact complexity depends on the implementation
(whatever tree traversal is done, as soon as something not equal is
found, failure can ensue).

Whenever you see ==/2, you should wonder whether you've made a mistake
in your design.  O'Keefe's book has a nice example of avoiding ==/2,
and improving both readability and efficiency, by using proper use of
functors [no, I won't tell you where this example is; you should read
the whole book anyway.]  And if you're using any of the "not equal"
predicates, you should make sure that things are properly ground; or
you should use a language that does delaying, such as NU-Prolog or
Life.
-- 
Peter Ludemann                      ludemann@netcom.com
