🚀 go-pugleaf

PROLOG Digest            Friday, 23 May 1986       Volume 4 : Issue 14

Today's Topics:
                   Administration - Order Restored,
         Implementations - Call_In & VMS/Prolog & KBES-Tools,
      & TRO & Exponentiation & Recursion & Compilation & Tricks
----------------------------------------------------------------------

Date: Fri 23 May 86 10:13:12-PDT
From: Chuck Restivo  <Restivo@SU-SCORE.ARPA>
Subject: Order

[cwr]

Many thanks to Mike Peeler for help with restoring order to
the MMAILR !

I apologize for not having put the Digest as frequently as
it should have been.  There have been a bunch of low level
details that have prevented me from producing it, and they
have now been addressed.

Best,
Chuck

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

Date: Wed, 9 Apr 86 11:20:20 est
From: Scott Guthery <sguthery%slb-doll.csnet@CSNET-RELAY>
Subject: Call-In to Edinburgh

Has anyone done or does anyone know about a program call-in
interface to Edinburgh C-Prolog?  The idea is to write

                list = cprolog("blender(X).");

and get back a list of blenders.  The hard bit seems to be
being able to assert things on the fly and find them later
without saving and restoring the world.

Thanks for your help,

-- Scott Guthery.

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

Date: 7 Apr 86 15:09:13 GMT
From: Chris Tweed
Subject: VMS/Prolog wanted

C-Prolog is available from:

EdCAAD
Dept. of Architecture
University of Edinburgh
20 Chambers Street
Edinburgh EH1 1JZ

Contact Mrs M. McDougall

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

Date: 29 Apr 1986 18:51-EDT
From: VERACSD@USC-ISI.ARPA
Subject: Benchmarking KBES-Toools

I have come across some recent benchmarks from NASA (U.S.
Gov't MEMORANDUM from the FM7/AI Section, April 3, 1986)
which compared various KBES tools' (ART, OP, KEE & CLIPS)
times for solving the MONKEY-AND-BANANA problem.  (This
toy problem is explained in detail along with OPS source
in Brownston et. al.'s "Programming Expert Systems in OPS5".)

Although the benchmarks include backward-chaining solutions
to the problem in both KEE and ART (along with forward
chaining counterparts), there is no PROLOG implementation
in the comparison.  I am very interested in a  PROLOG
comparison, and am in the process of implementing one.

Unfortunately, I am not (yet) a competent PROLOG programmer
and am currently learning my way around PROLOG on a DEC-20.
Consequently, any advice/suggestions re implementing this
benchmark and timing it effectively would be be useful &
appreciated.  (By the way, the time to beat is 1.2 secs. for a
forward-chaining implementation using ART on a 3640 with
4MB main-memory.)

I would be glad to share the results with anyone who offers
assistance. (Or for that matter with whomever is interested.)

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

Date: Mon, 31 Mar 86 20:11:03 pst
From: Peter Ludemann <ludemann%ubc.csnet@CSNET-RELAY>
Subject: response to Prolog Digest   V4 #12

Warren Abstract Machine ("WAM") bibliography.

Warren, D.H.D.: An Abstract Prolog Instruction Set.  SRI
Technical  Note 309.  - the basic description.

Gabriel, Lindholm, Lusk, Overbeek: A Tutorial on the Warren
Abstract  Machine for Computational Logic.  Argonne National
Laboratory Report ANL-84-84.  - amplifies SRI 309.  The
description of how WAM avoids putting entries on the "trail"
needs careful reading - it's a bit terse (but correct).
The rest of the paper is quite good.  I would recommend
starting with this paper.

Tick, E. and Warren, D.H.D.: Towards a Pipelined Prolog
Processor.   IEEE 1984 International Symposium on Logic
Programming.  - gives a  description of a hardware
implementation for SRI 309.  The description of WAM is
a bit terse, but probably adequate if you read carefully.

Warren, D.H.D.: Implementing Prolog - Compiling Predicate
Logic  Programs.  Technical Reports 39 and 40, Department
of Artificial  Intelligence, University of Edinburgh.
- describes compiling (into  DEC-10 code, although the the
papers are done mainly in terms of pseudo-code).  Also describes
tail recursion optimisation.  This is  mainly of historical
interest but some of the concepts are useful for  understanding
SRI 309.

==================

One of the nice things about the Warren design is its tail
recursion optimisation (TRO).  TRO helps solve the problem
of running out of stack space which was mentioned in Prolog
Digest V4 #12.  (As far as I'm concerned, any Prolog wihtout
TRO is just a toy.  And TRO isn't very hard to implement.)

There are many people who are implementing variations of WAM
(including myself).  I would appreciate hearing about these
other designs.

-- Peter Ludemann

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

Date: Fri, 4 Apr 86 15:09:45 MET
From: Neideck%Germany.csnet@CSNET-RELAY.ARPA
Subject: Exponentiation Bug

Answer to the "exponentiation bug" of Srinivas Sataluri in
Vol 4, No. 12

The bug isn't really caused by the exponentiation operator,
it should be possible to produce similar results with the
other arithmetic functors.

Since the integer 8 and the real number 8.0 are two different
constants they would not normally unify. C-Prolog performs
all internal arithmetic in double precision floating point,
then checks whether the result can be represented as an
integer. Thus every result without a fractional part should
be returned as an integer.

To see what's wrong, define a predicate real/1:

        real(X) :- number(X),not integer(X).

Then the following strange computations are successful:

        ?- X is 2^2, real(X), Y is X, integer(Y).
           X = 4
           Y = 4

The real error is with the function "Narrow" from "arith.c"
which checks, whether a number f can be represented as an
integer:

*****> if ((double)(k = (int)f) != f) return FALSE;  <******

The test ist carried out with the full double precision input,
but the actual result returned is of even less than single
precision, since the return value to C-Prolog is squeezed into
32 Bits together with a few tag bits. Differences in the
vanishing parts of the mantissa inhibit the conversion of the
result to  integer format, though the actual value does not
show any perceivable reason for this. Therfore "rule2" works,
as
        P is Z

performs the necessary conversion to integer format for Z.
The  test in Narrow should be less precise to counter this
misbehavior.  Ideally one should remove all the spurious
mantissa bits by doing

        f = XtrFloat(ConsFloat(f));

at the beginning of Narrow, but as both of them are genuine
functions, this comes out expensive, so I suggest the following
fix, which comes close:

double f; int *i;
{
    register int k;
    float imprecise;

    imprecise = f; f = imprecise;       /* Drop mantissa bits */
/* Better:  f = XtrFloat(ConsFloat(f)); but is rather expensive*/
   if (f < MinInt || f > MaxInt)  return FALSE;
    if ((double)(k = (int)f) != f) return FALSE;
    *i = k;
    return TRUE;

-- Burkhard Neidecker

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

Date: Fri 4 Apr 86 19:14:06-PST
From: Fernando Pereira <PEREIRA@SRI-CANDIDE.ARPA>
Subject: Recursion in Prolog

The three ingredients that you need to make recursion
affordable in Prolog are the following features in your
Prolog system:

        - tail recursion optimization
        - global (structure) stack garbage collection
        - a compiler that recognizes common deterministic
          idioms

Prolog-10/20 has had all three for 7 years, with the result
that it is possible to write the natural recursive formulations
of problems rather than being forced into horrible contortions
with assert and fail.

Summary: find a Prolog that uses today's technology, not
yesterday's...

-- Fernando Pereira

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

Date: Fri 4 Apr 86 19:19:24-PST
From: Fernando Pereira <PEREIRA@SRI-CANDIDE.ARPA>
Subject: Prolog compilation

Some of DHD Warren's papers, including the ones mentioned,
have also appeared as SRI technical reports. Write to

        Tonita Walker, EJ257
        Artificial Intelligence Center
        SRI International
        333 Ravenswood Ave.
        Menlo Park, CA 94025

The relevant report numbers are 290 and 309.

-- Fernando Pereira

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

Date: 2 Apr 86 20:09:39 GMT
From: Emneufeld@ucbvax.berkeley.edu
Subject: Prolog Hacker Tricks

If there is already a book on this subject, someone please
let me know.  Prolog is wonderful, but it has its unique
problems; some of which can only be dealt with by a bit of
hacking.  The following trick was shown to me by a friend:

To save space, use

      not ( not ( predicate (X ...))))

in place of `predicate (X ... )' where you are interested
just in the success of the predicate and not any values it
might return.  (Why does it work?) If the predicate succeeds,
the meta-predicate not fails, bindings are undone and stack
space is freed.  Second not returns success.  If the predicate
fails, nothing is saved, but you get the answer you wish.)

Send your favourite hack.

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

End of PROLOG Digest
********************