Subject: AIList Digest V4 #67

From: vtcs1::in% ([email-masked])
Date: Wed, 9 Apr 86 01:03:05 est

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 <[email-masked]>
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
[email-masked] (arpa)
dourson@gmr                        (csnet)

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

Date: Wed, 26 Mar 86 14:27:00 pst
From: George Cross <[email-masked]>
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                [email-masked]
 Computer Science Department    [email-masked]
 Washington State University    [email-masked]
 Pullman, WA      99164-1210    Phone: 509-335-6319 or 509-335-6636

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

Date: 27 Mar 86 09:12 EST
From: [email-masked]
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 <[email-masked]>
Subject: towards better documentation

   Date: 18 Mar 86 14:17:00 GMT
   From: [email-masked]
   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: [email-masked]
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 <[email-masked]>
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  <[email-masked]>
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: [email-masked]
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 [email-masked]
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: [email-masked] (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 <[email-masked]>
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" <[email-masked]>
Subject: AI languages

    From: [email-masked]

    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: [email-masked]
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 <[email-masked]>

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: [email-masked]
UUCP: ...!ukc!qmc-cs!qmc-ori!gcj

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

End of AIList Digest
********************