46.txt

This complete matlab for neural network

rehensible or ill-organized as often as because they don't have anything to sa
y. 

·       Circulate drafts for a while before sending it in to the journal. Get
 and incorporate comments. Resist the temptation to hurry a result into public
ation; there isn't much competition in AI, and publication delays will outweig
h draft-commenting delays anyway. 

·       Read some back issues of the journal or conference you are sub mit ti
ng to to make sure that the style and content of your paper are appropriate to
 it. 

·       Most publications have an ``information for authors,'' a one page sum
mary of what they want. Read it. 

·       The major conferences choose prize papers on the basis of excellence 
both of content and presentation from among those accepted. Read them. 

·       It's often appropriate to send a short, early report on a piece of wo
rk to a conference and then a longer, final version to a journal. 

·       Papers get rejected---don't get dejected. 

·       The reviewing process differs greatly between journals and conference
s. To get quick turn-around time, conferences must review quickly. There is no
 time for contemplation or for interaction. If you get bounced, you lose. But 
with a journal, you can often argue with the editor, and with the referee thro
ugh the editor. 

·       Referees should be helpful. If you get an obnoxious referee report, y
ou should complain to the program chair or editor. Don't expect much feedback 
from conference referee reports. But from journals, you can often get excellen
t suggestions. You don't have to do all of them, but if you don't you should e
xplain why, and realize that it may take further negotiation. In any case, no 
matter which side of the reviewing process you are on, be polite. You are goin
g to be working with the people whose papers you review as part of a community
 for the rest of your professional life. 

·       MIT AI Lab Memos are generally of publishable or near-publishable qua
lity. De facto, Technical Reports are almost always revised versions of theses
. Working Papers can be and often are very informal. They are a good way to ge
t a lot of copies made of a paper you'd want to send to a bunch of colleagues 
anyway. You publish one of these internal documents by getting a form from the
 Publications Office (just off the eighth floor playroom) and getting two facu
lty members to sign it. 

Like all else in research , paper writing always takes a lot longer than you e
xpect. Papers for publication have a particularly insidious form of this disea
se, however. After you finally finish a paper, you send it in for publication.
 Many months later it comes back with comments, and you have to revise it. The
n months after that the proofs come back for correction. If you publish severa
l forms of the paper, like a short conference version and a long journal versi
on, this may go through several rounds. The result is that you are still worki
ng on a paper years after you thought you were through with it and after the w
hole topic has become utterly boring. This suggests a heuristic: don't do some
 piece of research you don't care for passionately on the grounds that it won'
t be hard to get a publication out of it: the pain will be worse than you expe
ct.


7. Talks
Talks are another form of communication with your colleagues, and most of what
 we said about writing is true of talking also. An ability to stand in front o
f an audience and give a talk that doesn't make the audience fall asleep is cr
ucial for success in terms of recognition, respect and eventually a job. Speak
ing ability is not innate---you can start out graduate life as a terrible publ
ic speaker and end up as a sparkling wit so long as you practice, practice, pr
actice, by actually giving talks to groups of people.

Some ways to learn and practice speaking:

·       Patrick Winston has a great short paper on how to give talks. He also
 gives a lecture based on it every January which simultaneously illustrates an
d describes his heuristics. 

·       If you feel you are a bad speaker, or if you want to be a good one, t
ake a course on public speaking. An intro acting class is also useful. 

·       If your advisor's students have regular research meetings, volunteer 
to talk about your stuff. 

·       The MIT AI lab has a series of semiformal talks known as the Revolvin
g Seminar. Volunteer to give one if you have something worth turning into an A
I memo or a conference paper. 

·       Learn enough about the Lab's various robotics projects so when your r
elatives or friends from out of town come you can give them a tour and a littl
e 60 second talk in front of each robot about it. (Your relatives and non-AI f
riends will usually love this; they won't be so impressed by the intricacies o
f your TMS.) 

·       Since revising a talk is generally much easier than revising a paper,
 some people find that this is a good way to find the right way to express the
ir ideas. (Mike Brady once remarked that all of his best papers started out as
 talks.) 

·       Practice the talk in an empty room, preferably the one in which you w
ill deliver it. Studies of context effects in memory suggest that you will rem
ember what you are going to say better if you have practiced in the room you d
eliver in. Practice runs let you debug the mechanics of a talk: what to say du
ring each slide, moving overlays around smoothly, keeping notes and slides syn
chronized, estimating the length of the entire talk. The less time you spend f
umbling around with your equipment, the more time you have left to communicate
. 

·       Practicing with a mirror or tape or video recorder is another alterna
tive. The lab has all three. They might help debug your voice and body languag
e, too. 

·       For a relatively formal talk---especially your Oral Exam---do a pract
ice run for half a dozen friends and have them critique it. 

·       Watch the way other people give talks. There are a lot of talks given
 by people visiting MIT . Attending such talks is a good way to get a taste of
 areas you aren't so familiar with, and if the talk turns out to be boring, yo
u can amuse yourself by analyzing what the speaker is doing wrong. (Going to a
 seminar is also a way to cure the mid-afternoon munchies...) 

·       Cornering one of your friends and trying to explain your most recent 
brainstorm to him is a good way both to improve your communication skills, and
 to debug your ideas. 

Some key things to remember in planning and delivering a talk:

·       You can only present one ``idea'' or ``theme'' in a talk. In a 20 min
ute or shorter talk the idea must be crystal clear and cannot have complicated
 associated baggage. In a 30 or 45 minute talk the idea can require some build
up or background. In an hour talk the idea can be presented in context, and so
me of the uglies can be revealed. Talks should almost never go on for more tha
n an hour (though they often do). 

·       The people in the audience want to be there; they want to learn what 
you have to say. They aren't just waiting for an excuse to attack you, and wil
l feel more comfortable if you are relaxed. 

·       Take at least one minute per overhead. Some people vary in their rate
, but a common bug is to think that you can do it faster than that and still b
e clear. You can't. 

·       Don't try to cram everything you know into a talk. You need to touch 
on just the high points of your ideas, leaving out the details. 

·       AI talks are usually accompanied by overhead transparencies, otherwis
e known as ``slides''. They should be kept simple. Use few words and big type.
 If you can't easily read your slides when you are standing and they are on th
e floor, they're too small. Draw pictures whenever possible. Don't stand in fr
ont of the screen. Don't point at the overhead if it is possible to point dire
ctly at the screen. If you must point at the overhead, don't actually touch th
e transparency since you will make it jerk around. 

8. Programming
Not every AI thesis involves code, and there are important people in AI who ha
ve never written a significant program, but to a first approximation you have 
to be able to program to do AI. Not only does most AI work involve writing pro
grams, but learning to program gives you crucial intuitions into what is and i
sn't computationally feasible, which is the major source of constraint AI cont
ributes to cognitive science.

At MIT , essentially all AI programming is done in Common Lisp. If you don't k
now it, learn it. Learning a language is not learning to program, however; and
 AI programming involves some techniques quite different from those used for s
ystems programming or for other applications. You can start by reading Abelson
 and Sussman's Structure and Interpretation of Computer Programs and doing som
e of the exercises. That book isn't about AI programming per se, but it teache
s some of the same techniques. Then read the third edition of Winston and Horn
's Lisp book; it's got a lot of neat AI programs in it. Ultimately, though, pr
ogramming, not reading, is the best way to learn to program.

There is a lot of Lisp programming culture that is mostly learned by apprentic
eship. Some people work well writing code together; it depends strongly on the
 personalities involved. Jump at opportunities to work directly with more expe
rienced programmers. Or see if you can get one of them to critique your code. 
It's also extremely useful to read other people's code. Ask half a dozen senio
r grad students if you can get the source code for their programs. They'll pro
bably complain a bit, and make noises about how their coding style is just awf
ul, and the program doesn't really work, and then give you the code anyway. Th
en read it through carefully. This is time consuming; it can take as long to r
ead and fully understand someone else's code as it would take you to write it 
yourself, so figure on spending a couple of weeks spread over your first term 
or two doing this. You'll learn a whole lot of nifty tricks you wouldn't have 
thought of and that are not in any textbook. You'll also learn how not to writ
e code when you read pages of incomprehensible uncommented gibberish.

All the standard boring things they tell you in software engineering class are
 true of AI programming too. Comment your code. Use proper data abstraction un
less there is a compelling reason not to. Segregate graphics from the rest of 
your code, so most of what you build is Common Lisp, hence portable. And so on
.

Over your first couple years, you should write your own versions of a bunch of
 standard AI building blocks, such as 

·       a truth maintenance system, 

·       a means-ends planner, 

·       a unification rule system, 

·       a few interpreters of various flavors, 

·       an optimizing compiler with flow analysis, 

·       a frame system with inheritance, 

·       several search methods, 

·       an explanation-based learner, 

whatever turns you on. You can write stripped-down but functional versions of 
these in a few days. Extending an existing real version is an equally powerful
 alternative. It's only when you've written such things that you really unders
tand them, with insight into when they are and aren't useful, what the efficie
ncy issues are, and so forth.

Unlike most other programmers, AI programmers rarely can borrow code from each
 other. (Vision code is an exception.) This is partly because AI programs rare
ly really work. (A lot of famous AI programs only worked on the three examples
 in the author's thesis, though the field is less tolerant of this sloppiness 
than it once was.) The other reason is that AI programs are usually thrown tog
ether in a hurry without concern for maximum generality. Using Foobar's ``stan
dard'' rule interpreter may be very useful at first, and it will give you insi
ght into what's wrong if it doesn't have quite the functionality you need, or 
that it's got too much and so is too inefficient. You may be able to modify it
, but remember that understanding someone else's code is very time consuming. 
It's sometimes better to write your own. This is where having done the half-do
zen programming projects in the last paragraph becomes real handy. Eventually