Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!genrad!grkermit!mit-vax!eagle!harpo!seismo!hao!hplabs!sri-unix!PROLOG-REQUEST@SU-SCORE.ARPA From: PROLOG-REQUEST@SU-SCORE.ARPA Newsgroups: net.lang.prolog Subject: PROLOG Digest V1 #9 Message-ID: <1838@sri-arpa.UUCP> Date: Mon, 13-Jun-83 01:32:00 EDT Article-I.D.: sri-arpa.1838 Posted: Mon Jun 13 01:32:00 1983 Date-Received: Wed, 8-Jun-83 15:00:31 EDT Lines: 212 From: Chuck Restivo (The Moderator)PROLOG Digest Tuesday, 7 Jun 1983 Volume 1 : Issue 9 Today's Topics: Administrivia - Bad Formatting of Predicate Fixed, Prolog Availability, Implementations - Performance ---------------------------------------------------------------------- Date: 6 June 1983 0806-PDT (Monday) From: Abbott at AEROSPACE (Russ Abbott) Subject: Formatting The formatting of my revised less_than_or_equal predicate for use in declaring predicates transitive apparently got fouled up in transit. It should be as follows. [ My apologies to all. -- Chuck ] less_than_or_equal(X, Y) :- integer(X), 0 is floor(X/10), % X is equivalent to Y if 1 is floor((X+1)/3) - floor(X/3), % floor(X/3) = floor(Y/3). Y is X - 2. less_than_or_equal(X, Y) :- integer(Y), 0 is floor(Y/10), % X is equivalent to Y if 1 is floor(Y/3) - floor((Y-1)/3), % floor(X/3) = floor(Y/3). X is Y + 2. less_than_or_equal(0, 1). less_than_or_equal(X,Y) :- integer(X), 0 is floor(X/10), Y is X + 1. less_than_or_equal(X, Y) :- integer(Y), 0 is floor(Y/10), X is Y - 1. ------------------------------ Date: 6 Jun 83 16:23:06 EDT From: Sean McLinden Subject: C-Prolog for VAX running 4.xx bsd UNIX Is there a version of Prolog available for Vaxes running Berkeley UNIX? If there is, how would I go about getting a copy? Thanks. Sean McLinden Decision Systems Lab University of Pittsburgh School of Medicine ------------------------------ Date: Mon 6 Jun 83 15:30:03-PDT From: PEREIRA@SRI-AI.ARPA Subject: Another Prolog in C Besides C-Prolog, which follows the DEC-10/Clocksin & Mellish dialect, there are a few other Prolog interpreters in C, none of which I have used myself. One of them, UNH-Prolog, seems to be also compatible with the DEC-10/Clocksin & Mellish dialect. It can be obtained for $100 from Prof. Jim Dept. of Computer Science University of New Hampshire Kingsbury Hall Durham, New Hampshire 03824 -- Fernando Pereira ------------------------------ Date: Mon 6 Jun 83 15:23:02-PDT From: PEREIRA@SRI-AI.ARPA Subject: Getting C-Prolog HOW TO GET C-PROLOG 30 May 1983 C-Prolog is a Prolog interpreter written in C for VAXes, but it will also run on MC68000 and Z8000 systems with enough address space. It will run both under Unix and VMS. C-Prolog is almost entirely compatible with DEC-10 Prolog and also very similar to the dialect of Prolog described in the book "Programming in Prolog" by Bill Clocksin and Chris Mellish. In contrast with most other Prolog systems, it handles floating-point numbers. Copies of C-Prolog can be obtained from EdCAAD Dept. of Architecture University of Edinburgh 20 Chambers Street Edinburgh EH1 1GZ Scotland (011-44-31)667-1011 x. 4598 There is a small handling charge for research and teaching uses, and a distribution for commercial purposes is also available. -- Fernando Pereira ------------------------------ Date: 1 Jun 83 10:59:05-PDT (Wed) From: harpo!seismo!presby!burdvax!mckay @ Berkeley Subject: More on LIPS and Benchmarking Problems In articles and talks about logic programming implementations and in this news group, the efficiency of a system is measured in "resolutions per second" or "logical inferences per second" (aka LIPS). These are usually mentioned in association with horn clause systems of various flavors, E.g. DEC-10/20 Prolog, LOGLISP. By far the fastest systems appear to be the DEC-10/20 Prolog systems which claim rates of 20,000 to 40,000 "resolutions per second" for compiled clauses. A benchmark is important because of interactions of the specific program being used and the definition of "LIPS". Consider the two obvious definitions. First, the one suggested by the use of the phrase "resolutions per second". This suggests one is measuring successful unifications of a literal with the head of a clause from some procedure as well as finding the appropriate clauses with which to attempt unification. This means that the measurement includes many unification attempts which may fail. It is extremely dependent on the order of clauses within a procedure and the clarity of the predicate involved. The measurement can be severely effected by the "shape" of clauses or literals. A second definition to consider is attempted unifications regardless of whether they fail or succeed. This would equate LIPS with unification. One still has the problem with the clarity of the literals involved but the problem with the order of clauses has been minimized. While unification is a critical component of a logic programming system, it by itself does not measure "progress" of a computation. All of this suggests that LIPS (whichever definition one uses) is extremely application specific and, therefore, if one is quoting a LIPS for a particular system one MUST state with what the measurement was done, I.e. a plain LIPS figure is is not good enough, it must be "LIPS with respect to X". Therefore: What is appropriate to measure for such systems? What are reasonable benchmarks? What have you used for benchmarks in the past? What AND WHY did you choose the specific logic programs as benchmarks? What measurements are there for the various systems? ------------------------------ Date: Sun 5 Jun 83 02:01:34-PDT From: PEREIRA@SRI-AI.ARPA Subject: LIPS again Although the author of the USENET article burdvax.781 is correct in theory about all the tricky factors than enter in any LIPS evaluation, in practice (8 years of it) the small set of benchmarks in David Warren's "Implementing Prolog" technical reports (available from the Dept. of Artificial Intelligence of Edinburgh University) seems to provide a good estimate of the performance of a Prolog system for a large variety of tasks. The figures of 40000 LIPS for DEC-20 Prolog and 1500 LIPS for C-Prolog on a VAX 780 come from timing "naive reverse" defined as follows: nrev([],[]). nrev([X|L],R) :- nrev(L,R0), conc(R0,[X],R). conc([],L,L). conc([X|L1],L2,[X|L3]) :- conc(L1,L2,L3). Although this is very simple, it tests the shallow backtracking and structure crunching which is charateristic of complex Prolog programs such as compilers, language parsers, term rewrite systems (E.g. algebraic simplifiers and equation solvers), theorem provers, etc. The program doesn't test deep backtracking and cut, but these seem to be comparatively fast in those systems that are good enough to be worth our trouble measuring. To get accurate figures for this kind of benchmark, we use a test program which calls nrev once to allocate space, page in, etc., then fails and goes into a fail loop calling nrev a number of times. For the benefit of those who don't have access to the "Implementing Prolog" papers, I intend to submit the collection of benchmarks and results for DEC-20 Prolog on a 2060 and C-Prolog on a VAX 780 in the near future. I hope this will provide a "de facto" standard for the evaluation of Prolog systems. -- Fernando Pereira ------------------------------ End of PROLOG Digest ********************