dave@quintus.UUCP (David Bowen) (07/12/90)
>About cuts and assert, I will only say that competent Prolog programmers >know that the fewer of them they use, the faster their programs are likely >to be. I agree with this statement but think it is dangerously misleading with respect to the use of cut. The most serious efficiency problem that people have with Prolog is that they fail to make logically determinate predicates actually determinate. If the Prolog implementation isn't able to spot the determinacy it has to keep backtracking information around indefinitely, which can waste arbitrary amounts of space. The simplest way to correct this is to add cuts at all appropriate places. Richard's point is that by careful design of your data structures and your program you can very often get all or most of your determinacy by exploiting first-argument-indexing, avoiding the need for cuts and ending up with a more efficient and more understandable program. He does not mean that you should simply leave out cuts to get speed. The text books that I have looked at do not explain this at all well.
jha@lfcs.ed.ac.uk (Jamie Andrews) (07/12/90)
In article <1396@quintus.UUCP> dave@quintus.UUCP (David Bowen) writes: >... If the Prolog implementation isn't able to spot the determinacy >it has to keep backtracking information around indefinitely, which can waste >arbitrary amounts of space. The simplest way to correct this is to add cuts at >all appropriate places.... This reminds me of something I've been wondering about for a while. Built-in "if-then-else" and "case" constructs are often touted as a way of getting around using cuts. What is the current wisdom about this? I know that not all uses of cut can be replaced by if-then-else, but what proportion of them can? (I seem to remember hearing some figure like 70% at one point -- don't know how this was measured, though.) On a related point, what proportion of instances of negation can be eliminated by using if-then-elses? (The problems of negation wouldn't be eliminated, of course, but if we could replace negation by if-then-else there would be more uniformity with other programming languages.) --Jamie. Original material copyright (c) 1990 by Jamie Andrews; jha@lfcs.ed.ac.uk for distribution only on unmoderated USENET newsgroups. "If you try to leave this room, I'll tackle you." -- Don Getty to Clyde Wells
px@fctunl.rccn.pt (Joaquim Baptista [pxQuim]) (07/13/90)
In article <5135@castle.ed.ac.uk> jha@lfcs.ed.ac.uk (Jamie Andrews) writes:
This reminds me of something I've been wondering about for
a while. Built-in "if-then-else" and "case" constructs are
often touted as a way of getting around using cuts. What is the
current wisdom about this? I know that not all uses of cut can
be replaced by if-then-else, but what proportion of them can?
(I seem to remember hearing some figure like 70% at one point --
don't know how this was measured, though.)
On a related point, what proportion of instances of
negation can be eliminated by using if-then-elses? (The
problems of negation wouldn't be eliminated, of course, but if
we could replace negation by if-then-else there would be more
uniformity with other programming languages.)
Do you know the work reported in:
%T UNL Prolog User's Guide Manual, version 1.0, draft
%A Antonio Porto
%A Luis Moniz Pereira
%A Luis Trindade
%P 11
%I Dept Informatica, UNL
%C Lisboa
%D May 1987
%R ALPES WP 9
%K =UNL-Prolog =Prolog Manual
%X The system described here is UNL Prolog version 1.0 running on top of
O'Keefe's Edinburgh C-Prolog version 1.5b.edai under the Ultrix operating
system.
If you heard about Two-Level Prolog, conceived by Antonio Porto, there are
a lot of things that you will recognize in UNL Prolog. UNL Prolog results
from the experience acquired in the use of the first system, which it aims
at improving.
One of the main intentions in the design of the system was to replace the
anarchical use of the cut with constructs or system predicates, that
express in a better way the intention of that use.
UNL Prolog accepts standard Edinburgh Prolog clauses for the sake of
compatibility. But if you want to start to use UNL Prolog, you should
do without standard Prolog, which is allways possible as there is no loss
of power with respect to Prolog.
--
Joaquim Manuel Soares Baptista, aka px@fctunl.rccn.pt, px@unl.uucp
Snail: CRIA, UNINOVA, FCT/UNL, 2825 Mt Caparica, Portugal
Confused? You won't be after the next episode of... Soap!