Newsgroups: comp.lang.prolog
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!oitnews.harvard.edu!purdue!lerc.nasa.gov!magnus.acs.ohio-state.edu!math.ohio-state.edu!news.cyberstore.ca!vanbc.wimsey.com!news.rmii.com!newsjunkie.ans.net!swiss.ans.net!europa.chnt.gtegsc.com!news.mathworks.com!newsfeed.internetmci.com!news.sprintlink.net!noc.netcom.net!ix.netcom.com!netcom.com!ludemann
From: ludemann@netcom.com (Peter Ludemann)
Subject: Re: complexity of ==/2
Message-ID: <ludemannDD44z1.LLA@netcom.com>
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
References: <LUDAESCH.95Jul24144618@malta.informatik.uni-freiburg.de> <ludemannDCwBMv.E2q@netcom.com> <40a6e6$c2i@gabriel.keele.ac.uk>
Date: Thu, 10 Aug 1995 20:59:25 GMT
Lines: 26
Sender: ludemann@netcom16.netcom.com

In article <40a6e6$c2i@gabriel.keele.ac.uk>,
Paul Singleton <paul@cs.keele.ac.uk> wrote:
>Peter Ludemann (ludemann@netcom.com) wrote:
>....
>: >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).
>
>... and as soon as identical pointers are encountered, the search can be
>pruned?

As soon as non-identical pointers are encountered, ==/2 can stop.
Because ==/2 will not have unified anything at that point (unlike
=/2), failure doesn't have to undo anything.  So, because it can avoid
any overheads of undoing unifications, ==/2 is likely to be faster
than =/2, but of the same complexity (if you think of the terms as
being a tree, the complexity is O(number of leaves)).  It's up to the
implementation whether the leaves are visited pre-order, in-order,
post-order, or something else; and whether the D-S-W algorithm can be
used or not; none of these decisions affect the average cost.

-- 
Peter Ludemann                      ludemann@netcom.com
