[comp.lang.prolog] PROLOG DIGEST V6 #49

restivo@POLYA.STANFORD.EDU (Chuck Restivo) (07/18/88)

Date: Mon, 18 Jul 1988 02:53-PST
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@POLYA.STANFORD.EDU>
Reply-to: PROLOG@POLYA.STANFORD.EDU>
US-Mail: P.O. Box 4584, Stanford CA  94305
Subject: PROLOG Digest   V6 #49
To: PROLOG@POLYA.STANFORD.EDU


PROLOG Digest           Monday, 18 July 1988      Volume 6 : Issue 49

Today's Topics:
                                        Query - TI -Resolution,
                             Implementation - Speed & Style,
                                            LP LIbrary - Vision
-----------------------------------------------------------------------------------------------------------------------------

Date: Wed, 13 Jul 88 15:10:21 MDT
From: shauninn@nmsu.CSNET
Subject: TI-Resolution

Does anyone know any references about the work of TI-resolution algorithm
by McSkimin and Minker in early seventies?  Please send me a message
if you know any such reference.  It will certainly be appreciated!

-- Shaun-inn Wu

------------------------------

Date: 14 Jul 88 23:38:03 GMT
From: debray@arizona.edu  (Saumya Debray)
Subject: "A Note on the Speed of Prolog"

The current (August 88) issue of ACM SIGPLAN Notices has an article
"A Note on the Speed of Prolog", by J. Paakki, that's
interesting.  The author reports on an experiment comparing the
speeds of compilers, written in Pascal and Prolog, for the
language Edison.  What's interesting is that even though the
Prolog implementation used is C-Prolog, the Prolog version of the
compiler is typically only about 5 times slower than the Pascal
version.  Now there are faster Prolog systems readily available
that are anywhere from 10 to 50 times faster than C-Prolog.
Assuming that the comparison is a fair one (i.e. noone's
writing execrable Pascal code or using the slowest Pascal system
available), this seems to suggest that using a "state-of-the-art"
Prolog system, one could actually have a Prolog version of the
compiler that was faster than the Pascal version.

--  Saumya Debray	 

-----------------------------

Date: 15 Jul 88 03:16:19 GMT
From: rochester!daemon@cu-arpa.cs.cornell.edu
Subject: Need style advice

I'd like some advice about how to clean up a relation.

foo_value/2 is intended to be a proper, single-valued, function.
Several clauses can be satisfied at the same time, so I'm depending on
the lexical ordering of clauses and the use of cut to give the proper
precedence among multiple satisfiable clauses and enforce a single
value.

  foo_value(X, value_1) :- forced_to_be_1(X), !.

  foo_value(X, value_2) :- relation_one(X, Y), not(forced_to_be_1(Y)), !.
  foo_value(X, value_2) :- relation_two(X, Y), foo_value(Y, value_2), !.

  foo_value(X, value_1) :- relation_one(X, Y), forced_to_be_1(Y), !.
  foo_value(X, value_1) :- relation_two(X, Y), foo_value(Y, value_1), !.

  foo_value(X, value_3).

Is there a better way to get the same effect?  "Better" can mean
more efficient, more aesthetic, closer to purely logical, fewer uses
of cut and not, or whatever metric experienced Prolog users use.  :-)

Some other notes:
  relation_two/2 contains no cycles.  (It is neither reflexive
  nor symmetric, nor are there any longer sequences XrY YrZ ... WrX.)

  forced_to_be_1/1 is a collection of ground literals.

  relation_one/2 and relation_two/2 can satisfy multiple second
  arguments for a fully instantiated first argument.

  It would be nice, but not essential, if both arguments could be
  given as unbound variables.  Normally, I try to satisfy
  foo_value(literal, V).

-- Stu Friedberg

------------------------------

Date: 15 Jul 88 22:53:51 GMT
From: quintus!ok@unix.sri.com  (Richard A. O'Keefe)
Subject:  Need style advice

In article <1988Jul14.231619.22145@cs.rochester.edu> stuart writes:
>  foo_value(X, value_1) :- forced_to_be_1(X), !.
>
>  foo_value(X, value_2) :- relation_one(X, Y), not(forced_to_be_1(Y)), !.
>  foo_value(X, value_2) :- relation_two(X, Y), foo_value(Y, value_2), !.
>
>  foo_value(X, value_1) :- relation_one(X, Y), forced_to_be_1(Y), !.
>  foo_value(X, value_1) :- relation_two(X, Y), foo_value(Y, value_1), !.
>
>  foo_value(X, value_3).

>  forced_to_be_1/1 is a collection of ground literals.
>  relation_two/2 contains no cycles.
>  relation_one/2 and relation_two/2 can satisfy multiple second
>  arguments for a fully instantiated first argument.

Note that the code as written is not steadfast:
	?- foo_value(X, value_3).
will succeed for ANY value of X, even when forced_to_be_1(X).
Remember: a cut at the end of a clause is almost always in the wrong place.

Would it be possible for you to tell us what the relation is supposed to
_mean_, rather than showing us the current version of the code?  For
example, the following values for forced_to_be_1/1 and relation_one/2
	forced_to_be_1(jim).		% "male"
	forced_to_be_1(tom).
	relation_one(tom, jim).		% "sibling"
	relation_one(jim, tom).
	relation_one(tom, mary).
	...
	relation_two(_, _) :- fail.	% "parent"
appears to satisfy the description given, yet both
	relation_one(tom, mary), \+forced_to_be_1(mary)
and	relation_one(tom, jim), forced_to_be_1(jim)
are true, so should foo_value(tom, value_2) or foo_value(tom, value_1)?

Presumably there is some finite number of Xs which you intend to assign
foo_values to.  If that number is not too big, why not just write a
program to generate the table and write the results to a file, then
compile that file?

------------------------------

Date: 14 Jul 88 06:53:49 GMT
From: ucsbcsl!cornu.ucsb.edu!nosmo@ucbvax.Berkeley.EDU
Subject: summary: Computer Vision and Logic Programming

Well,

Some of you may remember my early posting, regarding the intersection of
computer vision and logic programming.  For those of you who replied, many 
thanks.

What was found:

Alan J. Vayda (vayda@ee.ecn.purdue.edu) is using prolog for high-level
object recognition on range data. Ref: Kak, Vayda, Cromwell, Kim and Chen,
"Knowledge-Based Robotics", Proc. of the 1987 Conf. on Robotics and Auto-
mation.

Ray Reiter and Alan Mackworth at Univ. of British Colubia have a paper
"The Logic of Depiction" (UBC TR 87-24) which proposes a theory of vision
based in first order logic. Net address: mack%grads.cs.ubc.ca@RELAY.CS.NET.
(note: Dr. Mackworth, I could never get mail back to you. My address is at
the end of this message.)

In vol. 1 of "Concurrent Prolog: collect papers", edited by E. Shapiro, MIT
Press, 1987, S. Edelman and E. Shapiro have "Image Processing in Concurrent
Prolog", this deals with algoritms for low-level vision. (edelman or udi,
@wisdom.BITNET)

Denis Gagne's thesis, from U. of Alberta, in Edmonton, home of the Oilers
and the West Ed. Mall, describes a reasoning approach to scene analysis.
The person that refered this to me didn't know the title, but did give me
a lead on how to find out. Randy Goebel (goebel@alberta.uucp) and David
Poole (dlpoole@waterloo.csnet) were Denis's advisors.

Mulgaonkar, Shapiro and Haralick, describe a rule-based approach for
determining shap-from-perspective in "Shape from Perspective: a Rule Based
Approach", CVG&IP 36, pp. 289-320, 1986.

That's about all that I've heard.  I'm still interested in hearing more,
though.

-- Vince Kraemer