Copy Link
Add to Bookmark
Report
AIList Digest Volume 4 Issue 067
AIList Digest Monday, 31 Mar 1986 Volume 4 : Issue 67
Today's Topics:
Applications - Machine Translation & Automated Documentation,
Book - Machine Learning: A Guide To Current Research,
Journals - Aviation Week Technical Survey &
Dr. Dobbs Journal AI Issue & AI in Engineering,
Theory - P = NP ?,
Linguistics - Ambiguity,
AI Tools - FORTRAN
----------------------------------------------------------------------
Date: Fri, 21 Mar 86 17:37 EST
From: Steve Dourson - Delco <dourson%gmr.csnet@CSNET-RELAY.ARPA>
Subject: Machine Translation of Documents
I am quoting the following article from the Dayton SIGART newsletter
dated March 13, 1986:
COMMERCIAL MACHINE TRANSLATION
Business Week (# 2912, 9/16/85, pp. 90D ff.) reports in an article by
Joyce Heard with Leslie Helm that several companies are active in
developing machines to produce commercial translations of documents.
This article describes translation systems that are currently
available for translating English, German, French, Spanish, Italian
and Japanese. Speeds of up to 100,000 words per hour are claimed, as
are accuracies of up to 90% and prices as low as $3000. (Not all the
same system of course). Customers are apparently willing to accept
rough translations as long as they can get them quickly; translators,
however, are not happy just polishing machine translations. Most of
the companies offering multilingual services are converting text to a
"neutral" language, then into the target language -- this greatly
reduces the cost of additional source or target languages.
-----
I haven't seen the original article. It may be worth investigating if
any of these machines could deliver a usable rough translation.
Perhaps the collection of papers could be machine-translated and
surveyed. Selected papers would be professionally translated.
Stephen Dourson
dourson%gmr.csnet@CSNET-RELAY.ARPA (arpa)
dourson@gmr (csnet)
------------------------------
Date: Wed, 26 Mar 86 14:27:00 pst
From: George Cross <cross%wsu.csnet@CSNET-RELAY.ARPA>
Subject: Re: towards better documentation
>>I am interested in creating an expert system to serve as
>>on-line documentation.
You probably want to look at Nathaniel Borenstein's dissertation
The Design and Evaluation of On-Line Help Systems
CMU, 1985 Available as Technical Report CMU-CS-85-151
In addition to a description of Borenstein's system, this has a large
bibliography and discussion of existing systems.
---- George
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
George R. Cross cross@wsu.CSNET
Computer Science Department cross%wsu@csnet-relay.ARPA
Washington State University faccross@wsuvm1.BITNET
Pullman, WA 99164-1210 Phone: 509-335-6319 or 509-335-6636
------------------------------
Date: 27 Mar 86 09:12 EST
From: WAnderson.wbst@Xerox.COM
Subject: towards better documentation
An excellent recent article entitled "Interactive Documentation" by P.J.
Brown (Computing Lab, The University, Canterbury, Kent) appears in the
March 1986 issue of Software -- Practice and Experience. The full
reference is:
Brown, P.J., Interactive Documentation, Software -- Practice and
Experience, Vol 16(3), March 1986, pp. 291-299.
He talks to many issues relating to display of documentation, and
describes a tool that "allows readers of computer-based documents to
peruse these documents at any desired level of detail" (from the
Abstract). Especially interesting is his distinction between
"replace-buttons" and "glossary-buttons."
Bill Anderson
------------------------------
Date: 27 Mar 86 10:36:08 est
From: Walter Hamscher <hamscher@ht.ai.mit.edu>
Subject: towards better documentation
Date: 18 Mar 86 14:17:00 GMT
From: pur-ee!uiucdcs!convex!graham@ucbvax.berkeley.edu
Subject: towards better documentation
I am interested in creating an expert system to serve as on-line
documentation. The intent is to abrogate the above law and
corollaries. Does anyone know of such a system or any effort(s) to
produce one? [...]
Frankly, it sounds like a black hole to me. Building an expert system
to do something that people don't know how to do very well is
generally a bad idea. The ubiquity of crummy documentation is prima
facie evidence that creating *good* documentation isn't yet a widely
understood art.
Nevertheless I'll toss some ideas out, first trying to figure out what
the functionality of this system is supposed to be.
Maybe you're talking about automatically generating documentation from
existing source code. You might start with Rich & Waters' stuff on
the programmers apprentice, also Bob Balzer's stuff at USC-ISI. See
IEEE Transactions on Software Engineering, November 1985, as one place
to start looking for lots of other related references. The problem
here is extracting the users-eye-view from an implementation. I would
think it would be easier to extract it from the original specification
(assuming it exists).
Another thing you might mean is building a ``user's assistant'' for a
complicated program. Along these lines I can suggest Mike
Genesereth's work (circa 1977, MIT) on the ``MACSYMA advisor,'' a
design with some interesting ideas. Also I seem to recall that people
have done expert systems for advising users on how to use a
complicated set of models embedded in a packages of dozens of FORTRAN
subroutines. E.g. statistical, econometric, ecological models. I
believe there was a paper in ECAI-84 on one of these, maybe Bundy was
an author (big help, eh?)? Also I believe there is an ongoing project
at Berkeley on a user's assistant for Unix. The idea is to be able to
ask it things like like ``how do I get these 90 files copied from one
machine to another'' and it makes a plan and guides you through the
steps, modifying the plan as it goes to deal with contingencies (e.g.
the machine you want to copy to turns out to have no network
connection so you have to make a tape). (I wonder what the program
says if you ask it ``how can I get back the files I accidentally
deleted?'' :-) To be useful the system needs to be able to generate
plans of action from its own knowledge of the program. Makes a good
forcing function on its knowledge.
Finally, maybe you just mean building an expert system that knows a
lot about a particular program, and presents hunks of canned text on
various topics. However, I don't see what such a thing could possibly
boil down to anything other than an index. Somebody still has to
figure out what to put in the index. To make it ``smart'' you need to
think about how to build that index automatically, or have it defined
implicitly by having the program search the hunks of canned text for
strings that match things the user is asking about. But then you have
the natural language problem on your hands again due to synonyms, verb
vs noun forms, etc. Ick. And the problem with this last approach of
course is that it doesn't abrogate Graham's Law: the canned text is,
after all, canned. The system is not an expert on the program, it's
an expert on the manual! The only way to abrogate the law is to have
the system look at the source code of the program... and then you're
back in the black hole again.
Well, good luck. I hope these ramblings may lead to something helpful
(and provoke errata from more knowledgeable readers).
-w
------------------------------
Date: 24 Mar 86 14:34:36 EST
From: GABINELLI@RED.RUTGERS.EDU
Subject: Machine Learning: A Guide To Current Research
[Forwarded from the Rutgers bboard by Laws@SRI-AI.]
MACHINE LEARNING: A Guide To Current Research (a collection of 77
papers--most of which were contributed by participants at the last ML
Workshop held in June, 1985) is being offered by the publisher,
Kluwer Academic Publishers, at a special pre-publication rate of
$27.95 (shipping included). This is a discount of 30% off the regular
price. [...]
Jo Ann Gabinelli
------------------------------
Date: Wed 26 Mar 86 09:08:28-PST
From: Oscar Firschein <FIRSCHEIN@SRI-IU.ARPA>
Subject: Aviation Week Technical Survey
AILIST readers might be interested in the following:
Aviation Week and Space Technology, Feb. 17, 1986 has a technical
survey of artificial intelligence, mostly applied to military
applications. Included are the DARPA-supported programs in Pilot's
Associate and the Autonomous Land Vehicle (ALV) and the VLSI lisp
machine being built by Texas Instruments.
Company profiles include McDonnell Aircraft's work in the Pilot's
Associate and avionics maintenance expert system; Boeing's AI Center;
MITRE's work in natural language understanding; Grumman's decision
support systems; Hughes AI center; and Westinghouse avionics
troubleshooting expert system.
------------------------------
Date: Fri 28 Mar 86 13:15:10-CST
From: Werner Uhrig <CMP.WERNER@R20.UTEXAS.EDU>
Subject: pointer: Dr. Dobbs Journal (April 86) The Annual AI Issue
TABLE OF CONTENTS
Programming in LISP and PROLOG
24 AI: BRIE - The Boca Raton Inference Engine
by Robert Jay Brown III
An exploration of artificial intelligence techniques, using LISP,
PROLOG, and Expert-2.
An Expert at Life
42 AI: A Cellular Automation in Expert-2
by Jack Park
Jack visited our pages two years ago with an expert system for
predicting the weather. This little game could teach even more
about AI tools.
46 AI: Modeling a System in PROLOG
by Sheldon D Softky
PROGLOG may be the language of choice for some very practical tasks,
says the author.
------------------------------
Date: WED, 10 JAN 84 17:02:23 CDT
From: E1AR0002%SMUVM1.BITNET@WISCVM.WISC.EDU
Subject: Journal - AI in Engineering
The International Journal for Artificial Intelligence in Engineering is
a new quarterly available from Computational Mechanics Publications,
subscription only, price $130. Please apply to Computational Mechanics Inc.,
Suite 6200, 400 West Cummings Park, Woburn, MA 01801, USA. (USA, Canada
and Mexico). Ashurst Lodge, Ashurst, Southampton SO4 2AA, England
for others.
------------------------------
Date: 29 March 1986 2129-EST
From: Andreas Nowatzyk@A.CS.CMU.EDU
Subject: P=NP Is this for real?
[Forwarded from the CMU bboard by Laws@SRI-AI.]
Article 355 of net.research:
From: ghgonnet@watdaisy
Title: P = NP by E.R. Swart, Department of Computing and Information
Science, University of Guelph, Research Report CIS86-02, February 1986.
Abstract:
A mathematical progamming formulation of the Hamilton circuit problem
involving zero/one restrictions and triply subscripted variables is
presented and by relaxing the zero/one restrictions and adding additional
linear constraints together with additional variables, with up to as
many as 8 subscripts, this formulation is converted into a linear
programming formulation. In the light of the results of Kachiyan
and Karmakar concerning the existence of polynomial time algorithms
for linear programming this establishes the fact that the Hamilton
circuit problem can be solved in polynomial time. Since the Hamilton
circuit problem belongs to the set of NP-complete problems it follows
that P = NP.
------------------------------
Date: Fri, 21 Mar 86 12:01:34 pst
From: Allen VanGelder <avg@diablo>
Subject: P=NP(?) still open
[Forwarded from the SRI bboard by Laws@SRI-AI.]
[...]
> From: lawler@ernie.berkeley.edu (Eugene Lawler)
> Subject: Swart's paper
> Not surprisingly, it seems to be fatally flawed. Bob Solovay started
> reading it carefully, found gaps in proofs, wrote Swart about them.
> The P=NP question is still with us, I believe. --Gene Lawler
------------------------------
Date: Wed, 26 Mar 86 14:28:58 EST
From: Bruce Nevin <bnevin@bbncch.ARPA>
Subject: ambiguity
Then there is this from the _Electric_Kool-Aid_Acid_Test . . .
on a tree at the foot of the driveway from the commune to the
main road was this sign:
No Left Turn Unstoned
A triple (at least) pun in four words!
Bruce
------------------------------
Date: Mon, 24 Mar 86 23:46:05 EST
From: "Keith F. Lynch" <KFL@AI.AI.MIT.EDU>
Subject: AI languages
From: gcj%qmc-ori.uucp@cs.ucl.ac.uk
Some AI packages soon could have interfaces to numerical code,
particularly those in process control; expert systems will make
decisions about a fault, then a simulation, written in FORTRAN,
will be run to see if the fix will work.
Why should the numerical routines be written in FORTRAN rather than
Lisp? Is this just for dusty decks, or is it proposed that new
FORTRAN code be written for this?
...Keith
------------------------------
Date: Wed, 26 Mar 86 13:24:52 GMT
From: gcj%qmc-ori.uucp@cs.ucl.ac.uk
Subject: Re: AI Languages.
> Why should the numerical routines be written in FORTRAN rather than
> Lisp? Is this just for dusty decks, or is it proposed that new
> FORTRAN code be written for this? /Keith Lynch <KFL@ai.ai.mit.edu>
I agree that LISP code can be faster than FORTRAN. Certainly MACLISP
produces fast numerical code. But most of the software effort for
numerical simulations, goes into FORTRAN, be it 66, 77 or 8X!
So they ain't just those dusty decks of cards.
Gordon Joly
ARPA: gcj%qmc-ori@ucl-cs.arpa
UUCP: ...!ukc!qmc-cs!qmc-ori!gcj
------------------------------
End of AIList Digest
********************
