JOHN TSITSIKLIS:
Thank you, Luca. Thank you for the invitation
to have this event. Thank you all for coming. So, I was told that
this is a good time to have such an event because
people over the summer start scrambling and
writing all the results that they had during the year. So that could be good
preparation here. All right, so what I'm
going to talk about, pretty much everything
is on a document that I have on my website. So you can go back
and refer to it, it's a document that I had put
together about 10 years ago. At that time I had a
large group of 10 students and instead of telling each
one every time the same things, I decided it would be more
efficient to put it on paper. I'm not sure they read it
but at least I did my part. Alright, so writing is a
serious business, why is it? You can think about it
in many different ways. Basically, you don't want
to waste your own time and wasting your
own time it means having to revise and
resubmit a paper three times. It's better to get it right
the first time, get it accepted and be finished,
it's more efficient. Also there's efficiency on the
other end of the communication channel, if the
readers can understand what you're trying to say then
you get your message across. If people take your
paper and set it aside after a few minutes then
you have not succeeded. So you have to take
things seriously and think from the point of view of the
people who will be reading it. Now, writing is
complicated because when you write a document
there's many levels at which you can think of it. It's like a fractal, there's
a high level structure, the big idea you want to
convey, but then there's lower level structures
and sub structures, it's very much like music. You can think of music
at different scales and all of these interact,
the macro and the micro, and one needs to spend time
thinking about all those scales at the same time. Alright, so what
I'm going to do is start with some high level
advice about document structure and all that. And then start going down to the
more pedantic and more pedantic elements, all the way to just
a few things about typesetting. I'm going to skip a
fair number of details that are in my document but
I'll try to pick and choose the most important ones. Alright, so what's the
highest level advice? The first thing is do not
think that your readers are super intelligent
and can read your mind. Rather you should assume
that the readers are somewhat tired and
maybe a little sleepy and you have to make it
an easy job for them, a pleasant job for them to
read through your document without having to stumble and
try to decode all the time. So that's a key
thing and that goes with a psychological attitude. Be insecure; do not
be overconfident, that my results are
great they speak for themselves and all that. Insecure means OK, I have to
really convince the others that I have something
interesting to say and that I'm saying it
in a loud and clear way. Now, another big advice is
to look at documents that you enjoyed reading and
sit down and think why did I enjoy reading
them, how do the masters do the job that they do. So in my own case, I was
happy to interact and write a lot together with two
great colleagues with Dimitri Bertsekas we have written a lot. And one of the things that
I learned from Dimitri is to try to cut out as much
junk or secondary material, just figure out what
is the main idea and try to express
it without things that are kind of second
order and not so necessary. And from Christos
Papadimitriou I learned how to write crisp
sentences that kind of strike the reader, that have some
rhythm, some smartness in them, that keeps the reader alert. To make the reader feel happy
even if they don't understand what they're reading, there's
an art that goes there. And it's always good
to refer, for example, to Nash's famous
paper on games which is just a page and a
few lines beyond that which is like a gem. It's a very crisp
document says exactly what needs to be said
nothing more than that. Alright, then the
next piece of advice is before you sit down in
front of your computer, instead spend a lot
of time thinking about what you're trying to do. So what is it you should
be thinking about, it's important to know
what your audience is. It's one thing to write a
tutorial for undergraduates, it's a different thing to
write for a machine learning conference, it's
a different thing to write for the annals of
mathematics or whatever. There's different
styles, there's different assumptions
you need to make about what your audience
knows and understands. So it's good to actually have
an image of a concrete person and saying I'm writing my
paper for Luca to read it and they have some
assumptions about what Luca knows and doesn't know
and gear it in that direction. Another important question is
why are you writing this paper? What is it that you want to say? It's not just
because you managed to collect 30 or 40 pages
of lemmas and results, it's because you have
a message to convey. There should be
some key takeaways that would be the
elevator pitch and have that clear in your mind. After someone reads your paper,
what are the three things that they should remember? And use that as the
anchor that guides the rest of your writing. OK, next step again before
you sit down on your computer write on pencil
or a pen on paper very precise statements of
the theorems or the lemmas that you are going to establish. Typesetting and thinking do
not go very well together, it's good to separate
the two of them. Without having to deal
with your keyboard, just have the exact
statements of the results that you're going to have. And in order to have
exact statements of your results of course,
you also need your notation. You're going to save a lot
of time in the long run if you just put aside
one sheet of paper and record all the notations
that you will be using. Of course, since you write the
paper your choices of notation might change but
at any time there should be one set of clear
notations that you are using and think about the choices
that you have there. So a choice that I particularly
like is that, to say, the convention that
random variables will be with capital
letters, real values will be with lowercase letters. Decide if you want to keep that
convention write it and keep using it, make a list of
the random variables that are going to show up in
your document and so on. And if you have processes that
evolve in time or functions, you have choices of notation
they have pros and cons decide ahead of time don't use this
notation in half of the paper and switch to x parentheses t
in the other half of your papers you'll drive your readers crazy. So make those decisions
ahead of time. And avoid stuff like this. OK, double subscripts
sometimes they're unavoidable but many times
there's ways to avoid them, keep the notation as
simple as possible. Alright and in the same
way as with notation decide what words
you're going to use. Just too many times
I've had to edit papers where the abstract
talks about agents and then the rest of the paper
starts to talk about nodes. OK, just decide
once and for all are you going to call them agents
or would you call them nodes. The stuff that
connects two nodes, you could call them
links, arcs, edges, whatever I don't care but
just pick one of those and stick to it. OK, it sounds a bit
trivial but actually if you don't make a conscious
decision in the beginning, you will find yourself drifting
between different words. Just at a low level,
some people like to spell queuing this
way some people like to spell queueing that
way I'm fine with either although I prefer the first
but just make that decision and stay consistent. Now, why does that matter? To some extent when I'm
editing a student's paper, my mental energy
should go into checking the details of
the proofs and not be distracted by correcting
hyphens here and there. So just in the interaction
with your co-authors or your advisors it's good to
get all those trivial details out so that one can
focus on the substance. Alright so once you
start again on paper you should write down the high
level outline of your document. Usually, in our field it's
pretty standard the way that things are structured
there's these key components. And within those
components again you want to think of them
in a modular way, so a section on results
might be 10 or 15 pages. You want to break it
up into subsections, sub subsections and all that
and use lots of headings. Having headings in bold
really helps the reader visualize the high
level structure of what's going on
whereas if you have five straight pages of
calculations and prose the reader starts to gets lost
and you need to help people orient themselves. So I'm thinking of
titles in sub subsections basically they're
signposts where are we now and what are we doing. And ideally there shouldn't
be anything more than two or three pages that's just
text after text after text. And each one of those modules
should have a clear purpose, it should be clear in your
mind when you sit down and write it what am I going to
do in this subsection, what is it that I'm going to deliver. And help the reader
by telling them, you can always try
to start a subsection with this boring
type of sentence. In this subsection,
we will deliver A, B,C and then go ahead
and deliver them. So as you can see,
almost everything I'm going to say
after you hear it, it's trivial, obvious,
not particularly deep but it's good to keep it
in mind and be systematic when you go into that business. All right, so let's
start from the beginning, we start with the abstract. So here's an abstract,
I took a real paper and paraphrased it so that
we can not tell what it was. So what would you say about
this type of abstract? It starts by saying
reinforcement learning does this blah, blah, blah,
blah, and then it says in this paper we do this. So how many people like
this kind of structure? How many dislike it? OK, so majority wins
that they dislike it, yeah what I really dislike
about an abstract of this kind is that the abstract is supposed
to just say in this paper, we do such and such,
editorializing, commentary, discussion about
the literature and philosophy and all that does not
belong to an abstract. All that blue stuff should not
be there instead the abstract should be very crisp and clear. Such as this is an example,
we consider this and that, we establish results 1,
2, 3, and by the way, we solved an open problem. All right, as opposed
to this boilerplate that people often do,
these sounds the way 100 other people wrote
papers on this topic without really
knowing why I'm also writing a paper on this
topic without knowing why, just because in recent years
many other people wrote papers, OK. Just avoid this "in
these recent years" just be simple, crisp
go directly to the point don't say more than
needs to be said. Then we move to the
introduction, unfortunately that's what most people
will read and then start stopping or lose energy. So your introduction
has to be really nice. Now, when you think
about what you're writing in the introduction it's
all pretty simple in your mind. So there's a temptation that
you just sit on your computer and just write whatever
comes to your mind that has some relevance to the
landscape of your paper but actually, it's very
useful to write down on paper what are the bullet
points that you're going to say and each bullet point should
be roughly one paragraph. And this way you can keep
your paragraphs distinct, a different paragraph should
have a different message from the previous paragraph. Don't keep a theme
running across paragraphs, don't keep your messages
tangled but keep them arranged and each one
having a particular function. So these days it's
pretty common to give a preview of the main
results in the beginning for those people who are
not going to read the rest. Usually that's not going to
be a precise theorem statement but you describe in words
our main results are 1, 2, 3, and sometimes if it's
in a crowded field you want also to say
exactly what's new and what are the
key contributions. The contributions could be
more than theorems could be, we have formulated for the
first time a model of such and such a kind and so on. These two sometimes you
can interleave them, sometimes you want to
keep them separately. There's a choice to be made but
again the point that I'm making is that there are choices to be
made, they are simple choices but you have to make
them consciously. Don't just go with the flow
and see what comes out. And it's good to conclude
the introduction section with some guide of
what's going to happen next, what's happened in each
one of the subsequent sections. Now, within sections
you think again that sections are going
to consist of modules of different types and
keep them in your mind as being separate that these
do not have a paragraph that has some motivation, some
discussion of a counter example and some discussion of
what other people did. These are different items, keep
them in separate paragraphs so a section typically
should start with, in this section we
will blah, blah, and these compeiments the
results in the previous section and so on. So again give to the reader
a sense of where we are now and where we're moving to. Give a little bit of discussion
so that the readers know where it's going, some details
whatever is necessary and then the typical
structure would be that you have a theorem. It's good to have a
paragraph if your theorem is complicated or
non-trivial that gives an interpretation
of what exactly it says what it doesn't say. It's sometimes good to give a
separate paragraph that gives the idea of the proof that
something that belongs outside the proof but says, the
proof that follows involves a sequence of steps
in which we do A, B,C so that the reader
has the high level view. I mean one can always read
proofs by going line by line and see if the next line
follows from the previous one but then you get
lost, to understand the proofs you really need to
extract the high level picture. Any proof should be
summarized in a sequence of three to 10 bullet points. You need to have those
bullet points in your mind and instead of having the reader
discover what those 10 bullet points are, it's even
better to just tell them that's the sequence
of high level steps that happen inside the proof. Now, something that's
very important whenever you have a
mathematical statement is to talk about
the counterexamples. If I remove this assumption,
the theorem fails and here's how it fails. Counterexamples give you
the boundary conditions for that theory when is it
true and when it is not. Examples of a special
case where one can really understand oh, that's
why it is true, examples are also important
and don't shy away from figures even though
they can take a lot of time to draw in the computer, you
can give a lot of intuition by giving a nicely
chosen figure. And something I
learned from Dimitri is that it's OK to have a
figure be an entire story. You can have a caption
that's a lots of lines and it's a self-contained story. The figure together with the
text underneath of the figure. Not everybody does that
but sometimes it works well and it's an independent piece
that you can look at and read on its own, it's like an
example with an illustration. All right, now the heart
of course, of math stuff are proofs. And usually we discover proofs
by thinking backwards that's what they want to prove in
order to prove that, I will try to prove this
intermediate result and that intermediate result
and to do that i would need to establish a few lemmas. So we go backwards
but it's very hard to read the long proof and
understanding and check correctness if it goes
in this backward way. So proofs should be written
in a linear way of course, in the beginning you can have
a discussion that perhaps you might have a comment like
this outside of the proof just to give the understanding
of how the thinking goes but the actual proof that
can be checked and verified needs to go in a linear way. So we start, we would
have lemmas, then use the lemmas to establish
the next Lemma and finally use that to
establish the final result. It's very hard to keep
track arguments that are incomplete where you
suddenly stop and you say Oh, for this
statement to be true, we will need to
prove something else but that something else,
I'm going to give it to you in three
pages later and all that it's hard to follow and
verify once you go nonlinear. So stay linear is a big
rule to follow of course, as I said outlining the
thinking that goes into it it's something that you
should do before starting the writing of the proof. Now, there's another
kind of style that sometimes
happens in textbooks as well, which is you
start discussing blah, blah, we have this and we have
that and we have that and now, oh, we just proved this
result. Rabbit out of the hat. And you impress your reader. I think that sometimes,
people do that when they prove Poincare's
or conjecture, or Fermat's last theorem. And they did that thing. It was a talk that it wasn't
clear where it was going. Then you impress your audience. But unless you are doing
something that big, it's better to tell the
reader ahead of time what you will be proving instead
of keeping them in suspense. OK, now somewhat of an
exception to the linearity is that we send some
stuff to appendices. But this, in a logical sense,
things are still linear. So your main text would
have limits A, B, C. D. Perhaps the proof of lemma
B is sent to an appendix. But the reader can still
read that linearly. And if they want to check
the technical details, they will go to the
appendix and check them. It's important
that the main text should be readable in
a self-contained way. I'm willing to accept that
the proof of the lemma is correct, which
is in the appendix. And I keep reading. And each step then follows
from the other step. You shouldn't
have-- you should be able to read the main
text without flipping to the appendix. That is, the main
text should not have a statements that says,
by lemma A3 in appendix C. Because then you would be
forced to flip to that lemma. Whatever lemma is used in the
main development of the theorem should be in the main text. Whatever lemma is referred
to in the main text should be stated
in the main text. The statement should
not be in the appendix. OK, now something that
sometimes causes me pain is that I read
something and then the miracle happens or
something like that. I do not see how the
next sentence follows from the previous sentence. And I spend 15 minutes trying
to reconstruct it, and check the algebra, and all that,
and all the time thinking, maybe it's something completely
obvious that I'm missing. Well, sometimes
people skip steps. And it's fine to skip steps. But you should alert the
reader, at this point, I'm skipping steps. Believe me, it's true. You shouldn't leave the
reader wondering, am I stupid? Is it something I don't see? Or should I need some work? So in such cases, it's best
to say by a short argument that's omitted here, or after
a moderately tedious algebraic computation, or whatever, just
tell the reader that there is stuff that's been hidden
so that they know that this is the case, so that they
understand that indeed there is stuff there. And maybe they want to
reconstruct it or maybe not. So it's really a
lot of pain when you're trying to see how
the next step follows from the previous step
and you're not quite told if that's a one-line
calculation that's omitted or is it a half a page
calculation that's omitted. That's very important from the
point of view of the reader. It's also very important from
the point of view as the writer because most of the mistakes
that are made in papers happen when you skip steps. You can see there's
something to be obvious. But just because you didn't
write it down explicitly, you might be missing some subtle
detail that makes your argument to be incorrect. Right, so now let's
move on to one level lower in the execution part,
and talk about language. All right, so here's
one possible translation of-- who recognizes the texts? OK, good. All right, so this
is one long sentence from The Stranger, the opening
words from The Stranger by Camus. And it's one sentence. Maman died today. But I do not-- for
sure-- it could be this-- blah, blah, blah. Well, the Nobel
Prize-winning version is that, which consists
of a few short sentences. I guess that was a style
that came into life-- yes, it's been
quite some time ago. Some people called
it the American style of writing literature, which is
with short, much to the point sentences. Now, in literature,
of course there's examples of the other extreme. You can read Proust
and have sentences that go for an entire page. And that's fine in
literature because they tried to evoke a
stream of thoughts that kind of moves and flows. But math is different. It's not supposed to
work by a feeling. It's supposed to work
in a different way. And for math, the
rule is whenever you see a long sentence,
try to break it up and try to make it into
a sequence of shorter, crisp sentences. Don't write a long sentence
that says this, this, this, and also this, this,
because this then that, and keep flowing that way. So it's enough
strain on your brain to try to understand the math. You shouldn't have
the extra strain of trying to parse a
complicated sentence. So long sentences
should be broken up. Just write with short sentences,
especially, of course, if English is not
your native language. That's even one more reason
to keep it short and simple. Other stuff about language-- OK, I have a preference for "we
show" instead of "it is shown." If you write your whole
paper in this passive voice, you started getting into awkward
phrases that do not quite feel right. So the "we" is a
good word to use. OK, now here's an example,
or counter-example. What's wrong with this sentence? Hmm? [AUDIENCE MEMBER ANSERS
QUESTION] It. It, yeah. What is that it? Now, the person who wrote that
sentence and the reader who understands the paper
of course understands that the dispatcher receives the
message and then the dispatcher is going to store the
information, the header. But that requires thinking. You shouldn't need to
do all that thinking to parse that sentence. It should be so
much simpler to say, when a message from a server
arrives to the dispatcher-- comma-- the dispatcher
stores the header. Your English teacher,
who might not be thrilled by the
repetition of the word dispatcher next to
itself so closely, but it saves a lot of
effort in interpreting. So pronouns are
basically pointers. But whenever you have the word
"it," sometimes it's ambiguous. There's many nouns
before that "it." And that it could be a pointer. Here, it could be a pointer. There, whenever there's even
a remote chance of ambiguity, you just make it explicit-- what
is it that you're pointing at? So that's a very common mistake. All right, so here's
another counter example. What's wrong with this? OK, many things that are wrong. If we define this-- OK, so you're telling me there's
a hypothetical universe where we might define it that way. But actually, we're
not defining that way. What is it that you're
trying to tell me? All right, and then
this, we have that. Here, your English
teacher would be really annoyed for good reason. OK, why not just say if x
equals to y then 2x equals 4y? It's saying exactly
the same thing as that's a long statement
with half as many words. Moral of this-- look
at every sentence after you're happy
with the math, that everything is correct, and
see what words are unnecessary. And just get rid of them. The shorter, the better. By the way, this point also
applies to sentences as well. You have a long paragraph
that's saying stuff. Look at each one of the
sentences in that paragraph and think, is this sentence
saying something new? Is it really needed or
can I get rid of it? Whenever in doubt,
just get rid of it. So the less, the better. Try to convey your message
in the simplest possible way. OK, here's another example. What's wrong with this one? OK, too many words. "Rests on the idea
of employing." The proof employs the
triangle inequality. You don't need the rest. So these are actual examples
from my proofreading of the last two weeks. So and it's very common. I mean, it's not a big deal. Nobody's going to reject
your paper because you had that kind of statement. But it's good to be
in the frame of mind, remove anything that's redundant
and stick to the substance. And apply that lesson also
to the higher level, not just to the individual
sentence level, but also to cutting
sentences, or even cutting remarks,
and side points, and things that are
not really necessary for the core of your paper. OK, that's another example in
the same vein, a true example. OK, what would you cut here? Well, using lemma
3, lemma follows-- what do you mean 'the
result" in lemma 3? OK, all right, so
you get the idea. The only exception where I am in
favor of putting something that could be cut is this thing. In common language, we would
say "assume n is an integer." And everybody
understands what we mean. But it kind of
flows nicer to say "assume that n is an integer." And depending on if it's inside
a more complicated sentence, it does help a lot to
parse that sentence if you have the word
"that" in the right places. All right, now let's switch
from English to math. I said that proofs
should be done linearly, that is the pieces of a
proof should be linear. To help the reading
of whatever you wrote, it's also nice that individual
sentences or pairs of sentences are also linear. And here's what I mean. OK, suppose we have these
great lemma that if n is even, then n is a composite number. By lemma 1, 2k is composite
because 2k is even. So that's also a true statement. Lemma 1 applies because
2k is even because it's-- OK, and because of that,
2k is a composite number. So this is non-linear
in the sense that this sentence at the end
is the sentence that is really saying the conditions of lemma
1 are satisfied, and therefore, by Lemma 1, 2k is composite. That's the logical
structure of the argument. So you should write it
in that way-- "following the logical structure,
know that's 2k is even, so the condition is satisfied. Therefore, by Lemma 1,
the conclusion follows." So write things in
exactly the way things are going, as opposed to saying-- an even worse case
could be a statement like, "because condition
A holds, lemma 2 applies. And this is because
condition D also holds." That is, you're
justifying a statement and the justification
has two parts. And you put one part of the
justification in the beginning, one part at the end. OK, it's all
understandable by someone who is going to spend
time trying to understand what you're saying. But the key point is that
your readers should not have to make any
effort to disentangle what you're writing. And writing things linearly is
the best way to go about it. So the ideal statements
are statements of the form "if such
and such is true, then such as such is true,
therefore such and such follows," and so on. Keep going in this linear way. Or define this term to
mean that, or to be this, and then we apply lemma
and it shows that. As opposed to, saying, "lemma
2 implies such and such, where x was defined to
be--" OK, sometimes we do that with the where, where
we put the justification afterwards if the sentences
would be awkward otherwise. But you do that only when
you're forced to do it. If you're not forced
to do it, start first by defining the terms and
then giving the statement that uses those terms. So ideal lemmas and theorems
should be short, ideally one line. OK-- OK, every Hilbert space
is a Banach space, period. That's your theorem. The definition of a Hilbert
space and the Banach space belong outside the theorem. Definitions should be outside. And then the comment,
"as a corollary L2 spaces are Banach spaces,"
that's a comment. It belongs outside the theorem. It should not be in the theorem. So the theorem should
be made as compact as possible by defining
notions, notations, concepts, all that outside them. And the theorem should be the
gem, or the central point. OK, something else
about math language-- here's some nice
variety: for all even integers this property holds. However, that property
holds if n is odd. OK, maybe it has some
variety in terms of language if you were writing a novel. But if you're writing
math, the reader would feel much more
at peace if the two sentences are exactly parallel. For even ones, that's true. For odd ones, that's true. I do not have to make any effort
to translate that statement, and turn it around, and compare
it with the first statement. So these parallel
constructions, even to have-- if you have two slightly
different theorems with two different conditions
in two different parts of your paper, it would be nice
to have the theorems structured in exactly the same way so that
one can compare them and see what assumptions are
different and what the assumptions are the same. Just try to follow templates. You will not get a literary
masterpiece this way. But you will get
something that's easier to understand and follow. And finally, whenever you
have math inside the text, math should be like something
that you can articulate using the English language. So how do you read that? "For every one less
than k less than 10--" what does it mean for every one? No, don't-- never do that. Unfortunately, here you would
have to say something longer. "For every k in the range
from 1 to 10," or "for every k belongs to the set to 1 to
10," something like that. Of course, we all
understand what this means. But you feel kind
of psychologically annoyed or unsettled
when you read "for every one less than k." All right, so that's
a good rule to follow. Math should read like English. OK, now perhaps a big-- a very common, recurring
point-- so in choosing what to talk about, I kind
of picked those things that do happen all the time. And one of them has to do with
ambiguities about quantifiers so look at that statement. "For every n, we have n
less than c for some c." OK, that sounds reasonable. If I pick c big enough, n
is going to be less than c. But this statement
can be interpreted in two different ways. "For every n, there exist some
c such that n is less than c." That's the first one. Or, "for some c, that
is there exists some c, such that for every n
we have n less than c." So in one statement it's
"for every, there exists" the other one is "there
exists for every." They are two
different statements. If you just write it
this way, it's not clear which one of the two you mean. Now, if you understand the
context and enough math, you will understand that
it's the first statement because the second
one is clearly false. But the reader should not have
to spend the time thinking is it this or is it that? Just write the
correct statement. So in unambiguous
statements, unfortunately we need to have all the
quantifiers in the beginning. You cannot put in the
quantifier "there exists c." If you put it at the
end of the sentence, it's ambiguous what is the
scope of that quantifier. So you shouldn't do that. Now, this phenomenon
of unclear quantifiers unfortunately happens
a lot once you start using this order
of magnitude notation. What does a statement--
so T is the running time of some algorithm. And you have a
theorem the T is order of n to the d, where n is
the number of data points and d is the dimension. That's a typical
kind of statement in a statistical paper. What does it mean? Order of magnitude
notation means there exists a constant,
such that eventually, except for the
beginning, you have an inequality of this kind. OK, there exists a constant-- there exists a constant,
depending on what? Here's one interpretation. There exists a constant such
that for a large enough n and d, we have this. That's one possible
interpretation. There's another
interpretation, a statistician who says, let us fix the
dimension of the problem. In that dimension, for
any fixed dimension there exists some c that
depends on the dimension, such that for all n large enough,
we have this relation. So the difference between
these two statements is that here c is an
absolute constant. Here, c is a constant that
depends on the dimension. They're very
different statements. How can you distinguish
between the two statements? You basically need to say very
explicitly which one of the two you mean. Whenever you have this
order of magnitude notation and multiple variables
inside there, you have to make it very clear
which variables are considered to be sort of fixed
and whether you're talking about the
dependence on n or the dependence
on both n and d. Ultimately, the only way
to be perfectly clear is to unfortunately
write it in full. You might say T, "our
result is the following--" that's the short statement-- "by which, more precisely--"
and then give the whole words. And it's important to
do that because these are two fundamentally
different statements. Sometimes you can save
it by adding here, by saying there is some
universal constant, c, and something like that. And there exists a
universal constant c, such that T is less than that. That almost gives the
idea what you mean, although universal
constant is not a very mathematical statement. What's the difference
between a constant and the universal constant? It's just helps the
reader a little bit when you use that
word universal. But if you want to be very
precise, it actually doesn't. So be very wary, worry a
lot about order of magnitude and notation to make sure
what exactly you're claiming. Unfortunately, especially
in conference papers of the type that gets produced
the night before the deadline, they tend to be full
of this kind of stuff. All right, now as we move down
to lower and lower levels, there's lots of little bits
of advice about typesetting. The list is infinite. I'll just pick some samples
that come to my mind. one is do not use
in-line fractions. They're ugly. They mess up with the fonts. You get things that look
small when they shouldn't. So in-line fractions should
not be displayed this way. They should be
displayed that way. It's just more beautiful. It doesn't mess up
with the spacing. Another one is to always
help the reader parse long expressions. So what's wrong with this one? It's a conditional expectation. But the conditioning
is that thin line somewhere in the middle. And your eye has to work a
lot to kind of identify it and split that in two pieces. How about this? Just add some space
here and there so that the two pieces are
separate from each other. It's a trivial point. Pretty much everything
I've said is trivial. But this saves mental
effort for the reader. And your work is to
make everything as easy as possible for the reader so
that they don't have to spend time on the annoying stuff. Just concentrate the mental
effort on the math and nothing else. OK, and if you look at the
documents on my website and also the references
in the next slide, they have long lists of dos and
don'ts of this type for the low level kind of writing. So Dimitri, a long time
ago, had a talk pretty much of this flavor. Now, Dimitri used the
advice that I didn't follow, which is to figure out,
really, what is your message? And he concentrated on 10
rules, whereas I gave you just a laundry list of rules. So there's very good
useful points there. Of course, one of the
rules is to write linearly. The other rule is to write
modularly, and so on. Knuth is, of course, the most-- I guess the person
one can think of when trying to think of someone
who's obsessive with detail and perfection. And so he has a huge
document about writing. But at least in the beginning,
there's concise stuff about dos and don'ts. And one of the things that
he's saying is never use-- we have that x equals to 3. Never. Just say we have x equals to 3. That has been a topic of lots
of debates between authors and co-authors, OK? I go with Knuth and say don't
put the word that in that place. And Halmos has a beautiful essay
that has quite a bit of humor and examples of dos and don'ts. It's very pleasant
evening reading. OK, so I'll stop here. Guess we have time for
questions, or thoughts, or reactions? [APPLAUSE] Has it ever happened to
you that you found yourself running out of notiation like
with the English alphabet and Greek alphabet [INAUDIBLE]? Mm-hmm, yes, sometimes you do
kind of run out of notation, especially you start exhausting
the letters for integers. You have I, J, K, L, M, N. And
then you need to add one more. And then you have
to be creative. But you'd never really run out. It's just that you have to sit
down and spend time thinking. Is it true that we
shouldn't use "we" even if we are writing
single author papers? You don't want to
say I in your paper. It's not polite, yeah. So you can imagine
writing your paper. So this paper shows
that blah, blah. The next step in the proof is-- you can manage without the "we." But at some point, you find
that it starts becoming clumsy. "I" doesn't sound-- And I doesn't sound-- yeah, it's-- Yeah? [INAUDIBLE] discuss the
figure [INAUDIBLE]---- Yes. It seems like [INAUDIBLE] Yes. Yeah. Yeah, we found it
useful in many-- so you can have
the figure and then discussion in the text about
what's happening in the figure. But if it's completely
self-contained, so the figure would be
geometrical interpretation of that proof. It has the figure. And underneath, it
says this segment is that, that is that because
those things are orthogonal, things are happening that way. And the figure can
be read independently of everything else. I guess I was [INAUDIBLE]. It fits more in books. But you can-- it's an option
to consider in papers as well. It's less common in papers. OK, all right. Thank you. [APPLAUSE]
