Following are short descriptions of four projects: two from my past, and two I'd like to tackle.




A Past Project:     Sensor-Based Navigation

The Navigation project grew out of a robot project when our company president asked us to build a system that could guide vehicles through cities without using GPS, the satellite location technology. (GPS does not work well in cityscapes and doesn't work at all in underground or indoor locations.) We analyzed alternative and competitive technologies, made a system design, selected hardware, designed other hardware, designed software, built a demo version, collected real-world data, redesigned it, rebuilt it, tested it and made it work. It was the world's first computer system ever to guide drivers through city environments in real time at highway speeds using visual input. We obtained various patents on the system.

As project manager I guided a team of 7 people through technical, legal, and personnel issues. A high level of enthusiasm, commitment, energy, focus, and productivity was maintained throughout. I managed the project budget, time schedules, quarterly reports, and deliverables.

I built relationships with customers, obtained funding, gave tours, contacted potential customers, inspired a Siemens-wide conference on transportation R&D, attended industry trade shows to assess market competition, wrote and delivered papers, interviewed customers' customers, made economic assessments of markets, differentiated market segments, designed product feature sets, and devised product sequence strategies.

The technical evolution of the project was noteworthy. We started out with a rather conventional approach to image processing and tried to model the objects in the visual field with concepts like "building", "tree", "doorway", "edge of roadway". As we progressed it became clear that although these labelings clearly could help us decide where the vehicle was located, it was not necessary to model them at this high cognitive level. In the end we had dispensed with all models that would be used in a conventional human description of a scene. Instead we relied on far more rudimentary features that were both much quicker to compute and much more robust indicators.

One technical lesson I learned from this project was to look diligently for ways to keep simplifying the problem before and after starting to solve it. Sometimes refining the requirements with a razor-thin redefinition can make a huge difference in solvability. The strategy is to:

This approach helps to achieve quick, cheap, effective, and satisfying solutions.

 

A Future Project:     Apparent Natural Language

Such a strategy for solving industrial problems can be applied almost anywhere, and I remembered it when I later encountered some problems in Information Retrieval and Natural Language Processing. The market for NLP has been greatly enlarged by the coming of e-Commerce to the internet, and it has been pent up by the long-standing lack of progress on the part of academic researchers trying to solve general versions of the NLP problem. Industry can often make great use of partial solutions. The trick is to be first to recognize those marketplaces where some customers have slightly less demanding situations, and to recognize those partial solution techniques that just fill the pared down requirements.

I believe I have identified at least one NLP market niche where feasible solutions are at hand. We could build a system for delivering what appears to be Natural Language communication in high-volume internet sites -- a very economical substitute for the telephone help line. It would have high economic value and wide application. It would reduce the cost of creating a knowledge base, the cost of maintaining it, the cost of human agents, the time it takes a customer to find information, and the cost of managing a help desk.

I am also seeking ways to enter into such a project as part of a collaborative academic program, or as an employee of or as a risk-sharing partner with a company that already addresses the CRM or NLP market.

 

A Long Past Project: Thesis and Book

My Ph.D. dissertation dealt with some issues and problems associated with the training of artificial Neural Networks. Although it had been well established that Neural Nets had some interesting abilities to absorb information, a stumbling block was the immense practical difficulties in getting them to do so in a reasonable amount of computer time. I decided to study the phenomenon and find out why this was so. The first step was to formalize the problem and set it in a form that was amenable to the type of analysis known as Complexity Theory. This is a branch of theoretical Computer Science that studies different classes of computational problems and stratifies them according to the amount of resources (like CPU time or memory) they necessarily consume. The first step was the most pathbreaking and difficult aspect of my undertaking.

Once I had a conceptual handle on what exactly was being computed, and what the Neural Net paradigm entailed for a computer, the big breakthrough was to notice and prove that it was computationally interchangeable with a famous complexity class known as NP-complete problems. These problems include a wide variety of common problems that are acknowledged to be infeasible to solve in a general way. This immediately answered the question as to why people were having a tough time training their Neural Nets. I went on, however, to find a whole structure of subproblems that were specializations of the general Neural Net training problem. Each one of them was eventually classified as feasible (Polynomial time) or infeasible. This laid out a description of the complexity-theoretic underpinnings of the network training enterprise.

The work not only won me a doctoral degree, but it generated enough clamour that MIT Press published the thesis in a book form. Neural Network Design and the Complexity of Learning was the best selling book in its series, and is still selling a decade later.



A Vision for the Future:     Cognitive Programming Assistants

Automatic programming is an attempt to help turn specifications for a program into working code. The field has been around for years, and progress has been slow. Automatic program verification is an attempt to augment working code with formal statements of properties and then find proofs that the properties will hold or not hold. The field has been around for years, and progress has been slow. Both these fields put the onus on humans to write "specs" that describe what the program should do. This has a certain circularity to it, and it is not surprising that it has proved very difficult both for the humans to write the specs and for the paradigm to exploit them. I think there is a less demanding ambition that sits beyond these two old paradigms, in which progress could be faster. It would involve building special-purpose tools out of general-purpose principles and some human-supplied (but informal) guidance regarding special properties of the specific application.

One such set of general-purpose principles would be the techniques used for "discrete search"-- something that is used in thousands of applications like scheduling jobs in a particular factory, or finding good layouts for chips, or finding solutions to assembly problems. Search algorithms have been very useful after a lot of R&D effort has been spent to tailor them to the specific problem being attacked. However, this effort can take many man-years and many calendar years to complete, and is prohibitively expensive for most applications.

The R&D effort involves two types of expertise: problem analysis skills and programming skills. My insight is based on noticing the kinds of knowledge that are being transferred from the problem analysis activity to the programming activity. It involves principles that characterize the search space and they form the foundation for the strategy in the resulting algorithms. It is not customary to formalize this knowledge nor to write it down --nor even to recognize it for what it is-- since the problem analyst is usually the programmer as well, and she need not expose the ideas crisply to anyone else. However, this knowledge is a gold mine; I believe it is the kind of knowledge that is missing from the program specifications that underlie automatic programming, and it is also missing from the information used in automatic verification. These two fields have made slow progress because they are lacking this information. Humans are quite good at perceiving this structural information. I believe we could make a successful system to extract such expertise from humans and automatically construct special purpose tools.