Copy Link
Add to Bookmark
Report
AIList Digest Volume 6 Issue 099
AIList Digest Monday, 9 May 1988 Volume 6 : Issue 99
Today's Topics:
Applications - Graphic Design & Chinese Character Cataloging,
Project Report - CMU Connectionist Road Follower,
AI Tools - Explorer (vs. Sun) Experience & Prolog vs. Lisp
----------------------------------------------------------------------
Date: 2 May 88 09:46:29 GMT
From: mcvax!ukc!strath-cs!glasgow!gilbert@uunet.uu.net (Gilbert Cockton)
Subject: Re: expert systems for graphic design?
In article <10712@sunybcs.UUCP> dmark@sunybcs.UUCP (David Mark) writes:
>It is my opinion that the content and components of maps in a geographic
>information systems (GIS) application vary so much that we cannot have
>"our layouts" to be evaluated by expert designers. Does anyone know of work
>which confirms or contradicts this, or knowledge of a graphics domain
>as complicated and variable as map production that has been 'solved' in a
>design sense?
There will never be a final 'solution' to many graphic design
problems, but as it is graphic designers who:
a) work with these problems all day
b) largely define (versions of) what aesthetics IS in the popular
consciousness
then I'm sure that good graphic designer's could improve the
subjective response to some layouts.
As far as cartography is concerned, the British Ordnance survey
redesigned their 1:50000 maps over 10 years ago and I'm sure that
there will be publications about this revision process and the
principles involved. Experienced map-users, as would be expected,
intensely disliked the changes to their user interfaces! I was a teenager
at the time, adjusted fairly quickly and now find it difficult to navigate
with the old maps. I'd say the U.K. O.S. had am improved 'solution' here.
For other forms of information, there is a substantial psychological
literature on information presentation. The results are piecemeal,
but they could be integrated into an interactive design assistant
(which some might even call an expert system!).
P.S. This is probably no longer a comp.ai discussion (unlike free-will :-))
Follow-ups to comp.cog-eng?
------------------------------
Date: 3 May 88 16:14:19 GMT
From: sunybcs!rapaport@boulder.colorado.edu (William J. Rapaport)
Subject: Re: how to recognize a chinese character
In article <527@vmucnam.UUCP> daniel@vmucnam.UUCP (Daniel Lippmann) writes:
>is there anybody knowing some computer-method to analize
>a chinese character to find his place in a dictionnary ?
You might want to implement the strategy used by James McCawley, in his
Guide to Chinese Characters for Eating in Chinese Restaurants (or some
such title--my copy of the book is at home), published by UChicago
Press.
------------------------------
Date: Thu, 5 May 1988 16:44-EDT
From: Dean.Pomerleau@F.GP.CS.CMU.EDU
Subject: Re: Need info on new CMU sidewalk rover
In a recent post concerning autonomous land vehicle work at CMU, Gary
Cottrell writes:
>I don't know who is working on it, but I heard from a usually reliable
>source that Dean Pomerleau (grad student at CMU, inventor of meta-connection
>networks) has a 3-layer back-prop network driving the thing better than the
>CMU vision group's system. Anyone care to confirm or deny this information?
>
>gary cottrell
I am working on a project called ALVINN (for Autonomous Land Vehicle In a
Neural Network). Currently ALVINN is quite proficient at driving on
simulated road sequences and a limited number of real roads stored on disk.
It hasn't been tested on the actual vehicle yet primarily because the van's
hardware is currently being upgraded but we are cautiously optimistic about
its ability to drive under field conditions. However it is too early to make
a comparison between ALVINN and the current ALV implementation here at CMU.
A paper discussing the project is being submitted to the November Conference
on Neural Information Processing Systems in Denver.
Dean Pomerleau
Computer Science Dept.
Carnegie Mellon University
Pittsburg, PA 15213-3890
pomerlea@f.gp.cs.cmu.edu (ARPAnet)
------------------------------
Date: Thu 5 May 88 21:10:37-EDT
From: Dave.Touretzky@C.CS.CMU.EDU
Subject: addendum to Pomerleau's message
For the record: Dean's preliminary experiments on *simulated* road images
give very good results. His experiments on 16 *real* road images also
gave good results, but that's way too few images to say anything conclusive
about how his net will compare with the CMU vision group's software.
While I personally think that the neural net approach can eventually outperform
other approaches on this simple road following task, and will do so shortly,
we don't have the data in hand to make public claims like that. Also, the
ALV task involves more than just road tracking. One must deal with things like
forks and intersections in roads; one must be able to use a map to keep track
of current position and navigate from starting points to arbitrary
destinations. Neural nets have not yet even been applied to these more
complex tasks. It's anybody's guess how well they'll perform.
-- Dave Touretzky
------------------------------
Date: Thu, 5 May 1988 12:15-EDT
From: Douglas.Reece@IUS1.CS.CMU.EDU
Subject: CMU Robots
Re Request by John Nagle and Gary Cottrell for information about the CMU
Terregator successor:
1. The current robot testbed is a vehicle called the Navlab. It was built
from a large Chevrolet van/truck and is completely self-contained, including
propulsion, electrical power, computers and sensors. It is being driven
on paved paths (it is too big for sidewalks). Current research is addressing
vision, control, and architecture. More details can be found from documents
like
Shafer, Stenz, and Thorpe, "An Architecture for Sensor Fusion in a Mobile
Robot," in Proc. IEEE International Conference on Robotics and Automation,
1986
CMU Robotics Institute Tech Reports on Strategic Computing Project, Road
Following, Navlab, etc.
Thorpe et al, "Vision and Navigation for the Carnegie-Mellon Navlab,"
Annual Review of Computer Science, Vol 2, 1987, pp 521-56
2. Dean Pomerleau's network did a nice job of identifying and locating a road
in synthesized noisy images. He has not yet tried it on the range of (real)
images that the vision/Navlab group has used. I suspect that with some more
work he will be able to find roads in more difficult images. He has not
tried to identify intersections. Although his network produces some very
simple control outputs, he has not tried to actually control a vehicle.
Doug Reece dreece@ius1.cs.cmu.edu
------------------------------
Date: 5 May 88 19:13:15 GMT
From: mcvax!ukc!its63b!aiva!jeff@uunet.uu.net (Jeff Dalton)
Subject: Re: Explorer (vs. Sun) Experience ?
In article <11061@mimsy.UUCP> nau@frabjous.UUCP (Dana Nau) writes:
>On the Lisp machines, Lisp is thoroughly integrated with the operating
>system, and as a result, you can quite easily do things with windows,
>menus, editing, debugging, etc., that would be pretty painful to do in
>Lisp on the Sun. For example, if I want a pop-up a menu on the explorer,
>I simply call a built-in Lisp function, giving it the menu title and menu
>entries, and telling what should be done for each menu entry. That kind
>of thing is substantially more difficult on the Sun.
I would think you could just call a built-in function, etc. This seems
more a question of what libraries are available than an inherent advantage
of Lisp machines.
Nonetheless, it is true that such things are easier at present on Lisp
machines.
Jeff Dalton, JANET: J.Dalton@uk.ac.ed
AI Applications Institute, ARPA: J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton
------------------------------
Date: 7 May 88 01:43:28 GMT
From: rochester!daemon@bbn.com (Brad Miller)
Subject: Re: Explorer (vs. Sun) Experience ?
Date: 5 May 88 19:13:15 GMT
From: jeff@aiva.ed.ac.uk (Jeff Dalton)
[...]
I would think you could just call a built-in function, etc. This seems
more a question of what libraries are available than an inherent advantage
of Lisp machines.
I think the more telling difference is your ability to change under a lispm
environment what is taken as immutable under UNIX. For example, if I want to
modify the scheduler slightly, I can do that *at runtime*, I don't have to
compile a whole new system to run. If I want to change a definition being
used in another process, again, I can change it *at runtime*. Thus, I can
write new modes for my editor, and test them out in the same session, not
reload and relink a new version of the editor and then test *that* out.
In general, one is provided with the source to the entire system, and any
function may be changed or advised (advice is giving a piece of code to be
run before, after, or around some definition. Thus if I don't want to
actually change some part of the compiler because it will change between
releases, but the interface will remain constant, I can advise it instead.
Since advice can be compiled, there is really no performance penalty to
doing this, it is a function of working on an object-oriented system.
Most importantly, a lispm does not distinguish between the 'user' and the
'kernel'. Everyone is one big happy address space. This has the advantage of
allowing you to reuse software as you see fit, not as some UNIX designer has
decreed your interface must be to the kernel. You are free to call directly
or modify any functions that would normally be inside of the kernel, e.g.
the scheduler example I brought up. Why write your own scheduler to run as a
single UNIX process when you can just modify your system's scheduler to
suit?
There are many other advantages to the lispm environment, but I'm just
attempting to address this issue of libraries. Several papers have been
published on the lispm programming environment(s), the more current of which
I'm sure e.g. Symbolics will be happy to provide you with. As a quick
starter, look at _Interactive Programming Environments_ by Barstow, Shrobe,
and Sandewall, but realize that the book was published 4 years ago, and all
of Xerox, TI and Symbolics have done much to advance the state of the art
since then.
----
Brad Miller U. Rochester Comp Sci Dept.
miller@cs.rochester.edu {...allegra!rochester!miller}
------------------------------
Date: 7 May 88 15:47:10 GMT
From: bbn.com!aboulang@bbn.com (Albert Boulanger)
Subject: Re: Explorer (vs. Sun) Experience ?
There are many other advantages to the lispm environment, but I'm just
attempting to address this issue of libraries. Several papers have been
published on the lispm programming environment(s), the more current of which
I'm sure e.g. Symbolics will be happy to provide you with. As a quick
starter, look at _Interactive Programming Environments_ by Barstow, Shrobe,
and Sandewall, but realize that the book was published 4 years ago, and all
of Xerox, TI and Symbolics have done much to advance the state of the art
since then.
Also, for a non-lispm oriented discussion of the advantages of single
address environments, see the article:
"Towards Monolingual Programming Environments" Jay Heering & Paul Klint
ACM Trans. on Prog. Lang. & Systems Vol7 No. 2 April 1985. 183-213.
Personally, I feel the house of cards that multiple address
programming environments collapse when it comes to error handling.
While it is possible to fix this, it is VERY VERY hard. Question: What
do you do when you get an error in somebody elses foreign-language
(non lisp) window system that you are using within lisp on, say, a UNIX box?
Can you debug the code within a lisp stack trace? Can you build an
interface to mix the stack traces together?
Albert Boulanger
aboulanger@bbn.com
Albert Boulanger
BBN Labs Inc.
ABoulanger@bbn.com (arpa)
Phone: (617)873-3891
------------------------------
Date: 6 May 88 02:53:44 GMT
From: quintus!ok@sun.com (Richard A. O'Keefe)
Subject: Re: Gibber in AI, social sciences, etc.
In article <050388.124141.sowa@ibm.com>, SOWA@IBM.COM (John Sowa) writes:
> The dialog between LISPers and Prologers is no
> more meaningful than the dialog between Catholics and Protestants in
> Northern Ireland.
> John Sowa
Er, just what dialogue between LISPers and Prologers are you talking about?
Here at Quintus (makers of the finest Prolog system in the known Universe)
our attitude to Lisp is "what good ideas can we steal". I refer to my copy
of CLtL about once a day. ZYX like Lisp so much they've even imitated its
syntax. Sussex (makers of PopLog) think the great thing about their product
is _very_ close coupling between Lisp, Prolog, and Pop. I suspect that
someone who argues for (Lisp|Prolog) on the grounds that (Prolog|Lisp) is
bad doesn't understand either.
------------------------------
End of AIList Digest
********************
