Date: Mon 9 May 1988 00:30-PDT From: AIList Moderator Kenneth Laws Reply-To: AIList@KL.SRI.COM Us-Mail: SRI Int., 333 Ravenswood Ave., Menlo Park, CA 94025 Phone: (415) 859-6467 Subject: AIList V6 #99 - Applications, Road Follower, Explorer vs. Sun To: AIList@KL.SRI.COM Status: RO 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 ********************