Copy Link
Add to Bookmark
Report
AIList Digest Volume 2 Issue 124
AIList Digest Monday, 24 Sep 1984 Volume 2 : Issue 124
Today's Topics:
Algorithms - Demonstration Idea Wanted,
Machine Translation - SIGART Special Issue,
Natural Language - A Generalized Phrase Structured Grammar in Prolog,
Expert Systems & Logic Programming - Kastner's Preference Rules in Prolog
----------------------------------------------------------------------
Date: 23 Sep 84 19:30:30 PDT (Sun)
From: Mike Brzustowicz <mab@aids-unix>
Subject: Demonstration Idea wanted
A non-network friend of mine needs to demonstrate to a class the importance
of detailed specifications. He has been trying to find a task which is easy
to do but hard to describe, so that half of the class can write descriptions
which the other half will follow literally and thereby fail to accomplish
the described task. Anyone have any ideas other than tying shoelaces or
cooking beef wellington? (Many people don't wear laced shoes and the
facilities available aren't up to cooking :-)). Thanks!
-Mike
<mab@aids-unix>
------------------------------
Date: Thu, 20 Sep 84 20:41 EST
From: Sergei Nirenburg <nirenburg%umass-cs.csnet@csnet-relay.arpa>
Subject: SIGART Special Section on Machine Translation
ACM SIGART SPECIAL SECTION
ON MACHINE TRANSLATION AND RELATED TOPICS
A special section on MT and related work is planned for
an early 1985 issue of the SIGART Newsletter.
The purpose of the section is:
1. To update the knowledge of the new paradigms in MT
in the AI community
2. To help MT workers to learn about developments in
AI that can be useful for them in their projects
3. To provide the MT community with updated
information about current, recent and nascent MT
projects
4. To help identify major topics, results and,
especially, directions for future research.
Contributions are solicited from MT workers, as well as all
workers in AI, theoretical, computational and applied
linguistics and other related fields who feel that their
work has a bearing on MT (machine-aided human translation;
automatic dictionary management; parsing and generating
natural language; knowledge representation for specialized
domains; discourse analysis; sublanguages and subworlds,
etc., etc.)
A detailed questionnaire to help you in preparing a
response is available from the guest editor,
Sergei Nirenburg
Department of Computer Science
Colgate University
Hamilton NY 13346 USA
(315) 824-1000 ext. 586
nirenburg@umass
If you know of people interested in MT-related
activities who are not on a net, please let them know about
this call.
The deadline for submissions is DECEMBER 1, 1984.
Electronic submissions are welcome
------------------------------
Date: Thursday, 13-Sep-84 18:49:25-BST
From: O'Keefe HPS (on ERCC DEC-10)
Subject: Availability of a GPSG system in Prolog
[Forwarded from the Prolog Digest by Laws@SRI-AI.]
This message is composed of extracts from the ProGram manual.
ProGram is a suite of Prolog programs that are intended to permit
the design, evaluation, and debugging of computer realizations of
phrase structure grammars for large fragments of natural languages.
The grammar representation language employed is that known as GPSG
(Generalized Phrase Structure Grammar). A GPSG grammar, as far as
ProGTram is concerned, has up to nine components as follows:
1. Specification of feature syntax.
2. Immediate dominance rules (ID rules).
3. Metarules which operation on the ID rules.
4. Linear precedence rules (LP rules).
5. Feature coefficient default values.
6. Feature co-occurrence restrictions.
7. Feature aliasing data.
8. Root admissibility conditions.
9. A lexicon.
All the major conventions described in the GPSG literature are
implemented, including the Head Feature Convention, the Foot
Feature Principle (and hence slash categories &c), the Control
Agreement Principle, the Conjunct Realisation Principle, lexical
subcategorisation and rule instantiation incorporating the notion
of privilege.
All the major parts of the grammar interpreter code are written
in standard Prolog (Clocksin&Mellish). Installation of the
system should be fairly simple on any machine of moderate size
which supports Prolog.
AVAILABILITY
1. The manual is "University of Sussex Cognitive Science Research
Paper 35 (CSRP 035) and can be ordered from Judith Dennison,
Congitive Studies Programme, Arts E, University of Sussex,
Falmer, Brighton BN1 9QN, for 7.50 pounds including postage.
2. ProGram is aprt of the standard Sussex POPLOG system and is
included, without extra charge, in all academic issues and
updates of the POPLOG system. POPLOG is available to UK
academic users for the sum of 500 pounds (special arrangements
apply to holders of SERC AI grants who have a VAX running UNIX).
Existing UK academic POPLOG users can obtain a free update of
the POPLOG system which will include ProGram. POPLOG runs on
VAXes under VMS and UNIX, and on Bleasdale BDC 680as under UNIX.
[RAOK: The Bleasdale is a 68000, POPLOG is on SUNs too by now.]
Non-educational customers (UK & overseas) who want ProGram with
POPLOG should order it through System Designers Ltd, Systems
House, 1 Pembroke Broadway, Camberley, Surrey GU15 3XH. This
company makes POPLOG available to educational institutions in
the USA for 995 dollars.
3. Academic users of other Prolog systems can obtain a magnetic tape
in UNIX "tar" format of the Prolog code of the ProGram system
free, together with a copy of "The Program Manual", provided they
pay the tape, postage, package, and handling costs (35 pounds).
Copies can be ordered from Alison Mudd, Cognitive Studies
Programme, Arts E, University of Sussex, Falmer, Brighton BN1 9QN
A cheque for 35 pounds made payable to "The University of Sussex"
should be enclosed with the order.
I have no connection with POPLOG, ProGram, or (save a recent visit
when I picked up the ProGram manual and saw PopLog running on its
home ground) with the University of Sussex.
Just to make sure you realise what ProGram is and isn't, it IS
meant to be a convenient toolkit for *developing* a GPSG grammar,
it is NOT meant to be the world's most efficient parser. The manual
warns you that "in general, automatic exhaustive parsing with more
than a few rules tends to be slow". You shouldn't need to know
any Prolog in order to use ProGram.
------------------------------
Date: Friday, 14-Sep-84 21:20:02-BST
From: O'Keefe HPS (on ERCC DEC-10)
Subject: Interpreting Kastner's Preference Rules in Prolog
[Forwarded from the Prolog Digest by Laws@SRI-AI. This is a declarative
specification of an expert-system interpreter. -- KIL]
I've always been quite impressed by the "EXPERT" stuff being
done at Rutgers, and when I read Kastner's thesis
Kastner, J.K.
@i"Strategies for Expert Consultation in Therapy Planning."
Technical Report CMB-TR-135, Department of Computer Science,
Rutgers University, October 1983. (PhD thesis)
I decided to write an interpreter for his rules in Prolog as an
exercise. The first version just came up with the answer, that's the
stuff that's commented out below. The second version left behind
information for "explanations":
chosen(Answer, Reason, WouldHaveBeenPreferred)
Answer was the answer, Reason was the text the rule writer
gave to explain his default ordering of the treatments, and
WouldHaveBeenPreferred are the treatments we'd have preferred
in this ordering if they hadn't been contraindicated
despite(Answer, Contraindications)
means that Answer was contraindicated by each of the problems
listed, but it was still picked because the preferred choices
had worse problems.
rejected(Treatment, Contraindications)
means that Treatment was rejected because it had the problems
listed. Every treatment will be rejected or chosen. Note: in
these two facts the Contraindications are those which were
checked and found to be applicable, less severe ones may not
have been checked. (This is a feature, the whole point of the
code in fact.)
You'll have to read Kastner's thesis to see how these rules are used,
but if you're interested in Expert Systems you'll want to read it.
Why have I sent this to the [Prolog] Digest? Two reasons. (1) someone
may have a use for it, and if I send it to the library it'll sink without
trace. (2) I'm quite pleased with the "no-explanations" version, but
the "explanations" version is a bit of a mess, and if anyone can find
a cleaner way of doing it I'd be very pleased to see it. I guess I
still don't know how best to do data base hacking.
A point which may be interesting: I originally had worst/6 binding its
second argument to 'none' where there were no new contraindications.
The mess which resulted (though it worked) reminded me of a lesson I
thought I'd learned before: it is dangerous to have an answer saying
there are no answers, because that looks like an answer. All the
problems I had with this code came from thinking procedurally.
:- op(900, fx, 'Is ').
:- op(899, xf, ' true').
:- compile([
'util:ask.pl', % for yesno/1
'util:projec.pl', % for project/3
'prefer.pl' % which follows
]).
% File : PREFER.PL
% Author : R.A.O'Keefe
% Updated: 14 September 1984
% Purpose: Interpret Kastner's "preference rules" in Prolog
:- public
go/0,
og/0.
:- mode
prefer(-, +, +, +),
pass(+, +, +, -),
pass(+, +, +, +, +, +, -),
worst(+, -, +, +, -, -),
chose(+, +, +),
forget(+, +),
compare_lengths(+, +, -),
evaluate(+).
prefer(Treatment, Rationale, Contraindications, Columns) :-
pass(Columns, [], Contraindications, Treatment),
append(Pref1, [Treatment=_|_], Columns), !,
project(Pref1, 1, Preferred),
assert(chosen(Treatment, Rationale, Preferred)).
pass([Tr=Tests|U], Cu, Vu, T) :-
worst(Tests, Rest, Cu, Vu, Cb, Vb), !,
pass(U, [Tr=Rest], Cu, Vu, Cb, Vb, T).
pass([T=_|U], C, _, T) :-
chose(T, U, C).
pass([], [T=_], _, _, C, _, T) :- !,
chose(T, [], C).
pass([], B, _, _, Cb, Vb, T) :-
reverse(B, R),
pass(R, Cb, Vb, T).
pass([Tr=Tests|U], B, Cu, Vu, Cb, Vb, T) :-
worst(Tests, Rest, Cu, Vu, Ct, Vt),
compare_lengths(Vt, Vb, R),
( R = (<), C1 = Ct, V1 = Vt, B1 = [Tr=Rest], forget(B, Cb)
; R = (=), C1 = Cb, V1 = Vb, B1 = [Tr=Rest|B]
; R = (>), C1 = Cb, V1 = Vb, B1 = B, assert(rejected(Tr,Ct))
), !, % moved down from worst/6 for "efficiency"
pass(U, B1, Cu, Vu, C1, V1, T).
pass([T=_|_], B, _, _, C, _, T) :-
chose(T, B, C).
worst([Test|Tests], Tests, C, [X|V], [X|C], V) :-
evaluate(Test), !.
worst([_|Tests], Rest, Cu, [_|Vu], Ct, Vt) :-
worst(Tests, Rest, Cu, Vu, Ct, Vt).
evaluate(fail) :- !, fail.
evaluate(Query) :-
known(Query, Value), !,
Value = yes.
evaluate(Query) :-
yesno('Is ' Query ' true'),
!,
assert(known(Query, yes)).
evaluate(Query) :-
assert(known(Query, no)),
fail.
chose(Treatment, Rejected, Contraindications) :-
assert(despite(Treatment, Contraindications)),
forget(Rejected, Contraindications).
forget([], _).
forget([Treatment=_|Rejected], Contraindications) :-
assert(rejected(Treatment, Contraindications)),
forget(Rejected, Contraindications).
compare_lengths([], [], =).
compare_lengths([], _, <).
compare_lengths( _, [], >).
compare_lengths([_|List1], [_|List2], R) :-
compare_lengths(List1, List2, R).
/*----------------------------
% Version that doesn't store explanation information:
prefer(Treatment, Rationale, Contraindications, Columns) :-
pass(Columns, 0, [], Treatment).
pass([], _, [T=_], T) :- !.
pass([], _, B, T) :-
reverse(B, R),
pass(R, 0, [], T).
pass([Tr=Col|U], I, B, T) :-
worst(Col, 1, W, Reduced),
!,
( W > I, pass(U, W, [Tr=Reduced], T)
; W < I, pass(U, I, B, T)
; W = I, pass(U, I, [Tr=Reduced|B], T)
).
pass([T=_|_], _, _, T). % no (more) contraindications
worst([], _, none, []).
worst([Condition|Rest], Depth, Depth, Rest) :-
evaluate(Condition), !.
worst([_|Col], D, W, Residue) :-
E is D+1,
worst(Col, E, W, Residue).
---------------------------------------------------------------*/
antiviral(Which) :-
evaluate(full_therapeutic_antiviral_dose_recommended),
prefer(Which, efficiacy,
[pregnancy, resistance, severe_algy, mild_algy ], [
ftft =[fail, rtft, at3, at1 ],
fvira=[fail, rvira, av3, av1 ],
fidu =[preg, ridu, ai3, ai1 ] ]).
go :-
antiviral(X),
write(X), nl,
pp(chosen), pp(despite), pp(rejected).
og :-
abolish(chosen, 3),
abolish(despite, 2),
abolish(known, 2),
abolish(rejected, 2).
------------------------------
End of AIList Digest
********************
