jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) (01/03/91)
In the book, _Principles of Functional Programming_, by Glaser, Hankin, & Till, it is stated, "the notion of global state that may change arbitrarily at each step of the computation has proved to be both intuitively and mathematically intractable." In classical structured programming, the use of global state was discouraged, but programmers tended to be undisciplined, and there never was any clear philosophy on how storage should be structured in a program. The solution offered by functional programming is to eliminate all state from programs. A functional program passes data around without ever storing it anywhere. In object-oriented design, the approach is to eliminate all shared data areas, and to encapsulate any state so that all access to it is localized. The argument of advocates of functional programming is that if you don't have a program state (i.e. side effects), you don't have to worry about anything going wrong. The advocates of object-oriented design say that it's easier to design and maintain a program where you nail down the state of something in an object, and keep the state encapsulated so that it can't be touched. Is the issue of program state really the crux of the issue of program tractability and of control of complexity in software engineering? It seems to me that the ability to localize program state is an essential requirement, but I don't see why it should be necessary to eliminate it altogether, as in functional programming. -- John Dudeck "If it's Object Oriented then by jdudeck@Polyslo.CalPoly.Edu definition it's A Good Thing". ESL: 62013975 Tel: 805-545-9549 -- D. Stearns
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (01/03/91)
In article <27823155.211e@petunia.CalPoly.EDU> jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) writes: > In the book, _Principles of Functional Programming_, by Glaser, Hankin, > & Till, it is stated, "the notion of global state that may change > arbitrarily at each step of the computation has proved to be both > intuitively and mathematically intractable." That's a nice religion but it's simply not true. I am working on a formal, quite mathematical, definition for the semantics of my Q language. Q supports nonpreemptive threads and some amount of parallel processing. It supports data hiding even better than Ada---Piercarlo, if you're reading this, I stole your ideas about visibility in the opposite direction. Yet the notion of global state proves quite useful in the definition. ---Dan Difference between Multics and Ada: Multics was ten years *ahead* of its time.
gudeman@cs.arizona.edu (David Gudeman) (01/03/91)
In article <27823155.211e@petunia.CalPoly.EDU> John R. Dudeck writes:
]
]In the book, _Principles of Functional Programming_, by Glaser, Hankin,
]& Till, it is stated, "the notion of global state that may change
]arbitrarily at each step of the computation has proved to be both
]intuitively and mathematically intractable."
That is something of an exaggeration. The mathematics of global
states is almost trivial compared to the mathematics of recursive
functions.
It's hard to argue the "intuitive tractability" of global states, but
clearly the thousands (millions?) of working programs written under
the notion of a global state might be considered a counter-example to
the claim.
--
David Gudeman
gudeman@cs.arizona.edu
noao!arizona!gudemanburley@pogo.ai.mit.edu (Craig Burley) (01/03/91)
In article <27109:Jan301:33:4391@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: In article <27823155.211e@petunia.CalPoly.EDU> jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) writes: > In the book, _Principles of Functional Programming_, by Glaser, Hankin, > & Till, it is stated, "the notion of global state that may change > arbitrarily at each step of the computation has proved to be both > intuitively and mathematically intractable." That's a nice religion but it's simply not true. I am working on a formal, quite mathematical, definition for the semantics of my Q language. Q supports nonpreemptive threads and some amount of parallel processing. It supports data hiding even better than Ada---Piercarlo, if you're reading this, I stole your ideas about visibility in the opposite direction. Yet the notion of global state proves quite useful in the definition. Yes, I have a much easier time thinking about any global state if I imagine that all procedures have an "implicit" argument passed among them that contains the global state (an array of bytes representing all of memory, if necessary, perhaps even including I/O). In the object-oriented model, a similar approach can be taken -- think of global state as one huge object (if necessary -- multiple smaller objects when it is easily shown they don't interact) that all other objects know about, and treat all reads and writes to that state as messages to that object. Then any intuitions or mathematics (proofs) become easier, I think. The higher up one can abstract the global state (the more distinct one can show all of its elements to be, and the "closer" each element can be to getting "absorbed" by a few functions or objects), the easier the state was to deal with in the first place. Note this does not mean it is wise to start a new project using lots of global state -- I'm just pointing out that one can understand existing systems using this approach. Dan, does your Q language (or your formal definition) use this technique, or something similar, to deal with the global state you use in its definition? -- James Craig Burley, Software Craftsperson burley@ai.mit.edu
aew@eosvcr.wimsey.bc.ca (Alan Walford) (01/04/91)
My feeling is that functional programming and statelessness makes proofs of program correctness easier and even tractable. Show the following to a mathmatician: x = 2 x = 3 and he/she will say one of the statements is untrue. Show it to a programmer and he/she would say x gets assigned 2 and then 3; x's final value is 3. Yes, this is a silly and trivial example but I think it does fundamentally show that allowing state in a program makes proving correctness all that more difficult. I think the only successful work in program correctness proving has be done in functional (ie. stateless) programming. Since OO is not stateless I think we are a long way off from program proofs of correctness. Is anyone doing work in this area and can give me counter-examples to my "OO difficult to prove correct" statement ? Alan Walford Eos Systems Inc. ...uunet!van-bc!eosvcr!aew aew@eosvcr.wimsey.bc.ca
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (01/04/91)
In article <8mq8u2w162w@eosvcr.wimsey.bc.ca> aew@eosvcr.wimsey.bc.ca (Alan Walford) writes: > Show the following to a mathmatician: > x = 2 > x = 3 > and he/she will say one of the statements is untrue. Show it to a programmer > and he/she would say x gets assigned 2 and then 3; x's final value is 3. A mathematician who knows what's going on might prefer to think about it like this: ``x = 2''(state) = (state where x holds the value 2) ``x = 3''(state) = (state where x holds the value 3) ``x = 3''(``x = 2''(state)) = (state where x holds the value 3) ``x = 2; x = 3''(state) = ``x = 3''(``x = 2''(state)) Yes, folks, ``x = 3'' is a function which acts upon a (global) program state to produce a new state. ``x = 2; x = 3'' is the composition of those functions. And so on. A programmer might think about it this way too. > Yes, this is a silly and trivial example but I think it does fundamentally > show that allowing state in a program makes proving correctness all that > more difficult. Yes, that is a silly and trivial example. What do the supposed mindsets of mathematicians and programmers have to do with whether functional programming encourages fewer bugs than object-oriented programming? > I think the only successful work in program correctness > proving has be done in functional (ie. stateless) programming. This is a nice religion too, but it's simply not true. ---Dan
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (01/04/91)
Ever feel like you couldn't see the bugs for the program? The more program state/variables/definitions/procedures visible from one code segment, the easier it becomes for bugs to hide in that segment. That's the real reason that each segment should be as localized as possible. It's not for ``mathematical appropriateness'' or for proving that correct programs are, indeed, correct; it's for improving your chances of detecting the bugs in buggy programs. In article <BURLEY.91Jan3074344@pogo.ai.mit.edu> burley@pogo.ai.mit.edu (Craig Burley) writes: > think of global state as one huge object Nice. > Dan, does your Q language (or your formal definition) use this technique, or > something similar, to deal with the global state you use in its definition? The language per se has very little to do with the formal definition; I'm writing the latter mostly to make sure I know what I mean by the semantics of the former. Q doesn't give the programmer any way to refer to the entire program state. ---Dan
lance@motcsd.csd.mot.com (lance.norskog) (01/04/91)
gudeman@cs.arizona.edu (David Gudeman) writes: >It's hard to argue the "intuitive tractability" of global states, but >clearly the thousands (millions?) of working programs written under >the notion of a global state might be considered a counter-example to >the claim. No, I don't consider the millions of working programs a counter-example, because I don't consider them to work. A program doesn't "work" because you (or somebody) thinks it works. A program "works" if it can be mathematically proven to work. Experience and operational time don't count. This isn't like quantum physics where observation decides the matter. Empirical evidence doesn't enter into it. Lance Prove the Mac works. C'mon, I dare you.
macrakis@gr.osf.org (Stavros Macrakis) (01/04/91)
In article <2474@motcsd.csd.mot.com> lance@motcsd.csd.mot.com (lance.norskog) writes:
No, I don't consider the millions of working programs a counter-example,
because I don't consider them to work.
A program doesn't "work" because you (or somebody) thinks it works.
A program "works" if it can be mathematically proven to work. Experience
and operational time don't count. This isn't like quantum physics where
observation decides the matter. Empirical evidence doesn't enter into it.
You are apparently assuming that `works' is equivalent to `works
perfectly'. Why should the verb `to work' mean something different
for programs than for (say) mechanical cash registers, corkscrews, or
rocket launchers? None of them work all the time, yet we can say that
they `work'.
It has been argued that programs must be proven to work because they
are mathematical objects. But what will the proof prove? Only that
they correspond to their mathematical specification. And what proves
that the mathematical specification corresponds to the desired
behavior? This is only possible in narrow fields.
I am certainly not arguing against proving (some) properties of (some)
programs. This can be interesting in many cases and can even be
cost-effective in some cases. However, an unproved program can still
be useful.
I would say it `works'.
-s
Stavros Macrakis
Open Software Foundation Research Institute
Mail: 2 av de Vignate, 38610 Gieres (Grenoble), France
Net: macrakis@gr.osf.org
Phone: +33/76.63.48.82 Fax: +33/76.51.05.32philip@pescadero.Stanford.EDU (Philip Machanick) (01/05/91)
In article <2474@motcsd.csd.mot.com>, lance@motcsd.csd.mot.com (lance.norskog) writes: > No, I don't consider the millions of working programs a counter-example, > because I don't consider them to work. > > A program doesn't "work" because you (or somebody) thinks it works. > A program "works" if it can be mathematically proven to work. Experience > and operational time don't count. This isn't like quantum physics where > observation decides the matter. Empirical evidence doesn't enter into it. > > Lance > > Prove the Mac works. C'mon, I dare you. Would you be so good as to provide a formal specification of the Mac as a starting point? Otherwise, we don't know what you're asking us to prove. -- Philip Machanick philip@pescadero.stanford.edu
jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) (01/05/91)
>In article <2474@motcsd.csd.mot.com> lance@motcsd.csd.mot.com (lance.norskog) writes: > No, I don't consider the millions of working programs a counter-example, > because I don't consider them to work. > > A program doesn't "work" because you (or somebody) thinks it works. > A program "works" if it can be mathematically proven to work. Experience > and operational time don't count. This isn't like quantum physics where > observation decides the matter. Empirical evidence doesn't enter into it. You are evidently a purist. In mathematics, certainly a theorem can't be said to be true until it is proven. But I don't think it is possible to insist that programming is essentially a mathematical exercise (despite the attempts of many to do so). I believe programming and software engineering is more of a management problem than it is a mathematical activity. The management of complexity can be performed without the explicit statement of formal specifications and the explicit application of formal proofs or a program transformation calculus. We do it all the time. But that doesn't mean that our programs would fail if submitted to a formal proof. The problem is not that the programs don't work, it's that our specification languages and our proof methods don't work. -- John Dudeck "If it's Object Oriented then by jdudeck@Polyslo.CalPoly.Edu definition it's A Good Thing". ESL: 62013975 Tel: 805-545-9549 -- D. Stearns
lance@motcsd.csd.mot.com (lance.norskog) (01/06/91)
jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) writes: >You are evidently a purist. In mathematics, certainly a theorem can't be >said to be true until it is proven. But I don't think it is possible to >insist that programming is essentially a mathematical exercise (despite >the attempts of many to do so). I'm not a purist at all. I don't much like mathematics. Program-proving is a separate and recognized part of "Computer Science", which has little to do with industrial programming. I view programming as much more a linguistic exercise than a mathematical exercise. The emphasis on mathematics unnecessarily drives away people (often female) who would be quite capable programmers but are not particularly interested in mathematics. I could complete a math bachelor's but I've never much liked the subject. >I believe programming and software engineering is more of a management problem >than it is a mathematical activity. The management of complexity can be >performed without the explicit statement of formal specifications and the >explicit application of formal proofs or a program transformation calculus. >We do it all the time. Here's another meaty subject. Programmers are not taught to be engineers. Programmers are taught to be poets. An engineer are trained to design something over and over again before building it, to be sure it's absolutely correct. A programmer is trained to mess around re-shaping costfree thought-stuff until he decides he's finished. This is one of the roots of the software gap. >But that doesn't mean that our programs would fail if submitted to a >formal proof. The problem is not that the programs don't work, it's >that our specification languages and our proof methods don't work. My biggest complaint about software is the extreme conservatism of programmers. Once something (C or Unix) is recognized to work vaguely well, it becomes enshrined. In the past 15 years the dominant programming system has changed from Basic to C, which I would peg at a 10% improvement. Meanwhile, hardware has improved possibly a million-fold in bang per buck. SUN's have been shipping with 19-inch graphics screens for 8 years, but they're still programmed with a text-based programming language. I think this should go to some other group. Lance
mdixon@parc.xerox.com (Mike Dixon) (01/07/91)
A program doesn't "work" because you (or somebody) thinks it works. A
program "works" if it can be mathematically proven to work.
Experience and operational time don't count. This isn't like quantum
physics where observation decides the matter. Empirical evidence
doesn't enter into it.
asserting that "true" is equivalent to "provable" is a pretty extreme
philosophical position. i suspect you haven't really thought about
where it leads to; most people find the consequences unacceptable.
if you're familiar with meta-mathematics, the point of godel's proof
was precisely that there are true statements (in number theory) that
can't be proven. if you're interested in less abstract things (e.g.
whether or not the disk gets reformatted), it seems even less
acceptable to equate "provable" with "true".
personally, i think the point of proofs (and other forms of reasoning,
formal or informal) is to give us some information about what the world
is like. in the case of program correctness, a proof helps me figure
out whether or not the program is correct, but doesn't *make* it correct.
in particular, as soon as you start writing proofs about subjects other
than number theory or geometry, you realize that proofs simply give you
a relation between one set of assumptions about the world (the "axioms")
and another set (the "conclusions"); they certainly don't give you any
magic handle on truth.
Prove the Mac works. C'mon, I dare you.
good example. think about it. what would a proof tell you? note that
a) i can prove the mac works trivially, if i chose the right axioms
(of course, that proof doesn't give me any confidence that it really
will work)
b) no matter what axioms you choose, the existence of a proof won't
guarantee that the mac will actually do what the documentation
says it ought to do (at the very least, your axioms will make
assumptions that the hardware functions correctly)
c) (back to the original topic of this thread)
you're not going to simplify this proof by eliminating "global state",
since what matters about the mac's behavior is precisely this state
(i.e. what's displayed on the screen, what's written to the disk, etc.).
--
.mike.mac@eleazar.dartmouth.edu (Alex Colvin) (01/07/91)
In fact, global program states are such useful things that I often need more than one.
diamond@jit345.swstokyo.dec.com (Norman Diamond) (01/07/91)
In article <27823155.211e@petunia.CalPoly.EDU> jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) writes: >Is the issue of program state really the crux of the issue of program >tractability and of control of complexity in software engineering? It is a crux, not the only one. >It seems to me that the ability to localize program state is an essential >requirement, but I don't see why it should be necessary to eliminate it >altogether, as in functional programming. Functional programming has its place too. Yes it makes proofs easier and programming harder, and syntactic constructs have not been developed well enough to bridge these issues. -- Norman Diamond diamond@tkov50.enet.dec.com If this were the company's opinion, I wouldn't be allowed to post it.
jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) (01/08/91)
> c) (back to the original topic of this thread) > you're not going to simplify this proof by eliminating "global state", > since what matters about the mac's behavior is precisely this state > (i.e. what's displayed on the screen, what's written to the disk, etc.). Good point. The global state of a program includes more than the program- defined memory locations. 'Functional' programs that manipulate I/O therefore must have global state... But from the programmer's perspective, object-oriented design encapsulates the screen, disk files, databases, comm channels, etc, as objects which have the behavior of that particular real-world entity. Thus the state aspects of those objects is still localized so as to help control complexity. -- John Dudeck "If it's Object Oriented then by jdudeck@Polyslo.CalPoly.Edu definition it's A Good Thing". ESL: 62013975 Tel: 805-545-9549 -- D. Stearns
mdixon@parc.xerox.com (Mike Dixon) (01/08/91)
But from the programmer's perspective, object-oriented design
encapsulates the screen, disk files, databases, comm channels, etc, as
objects which have the behavior of that particular real-world entity.
Thus the state aspects of those objects is still localized so as to
help control complexity.
the problem is that these objects aren't encapsulating the real state
-- nor could any programming language construct. you can go ahead and
define a disk file object that "encapsulates" and controls access to
your disk file, but if i start sending arbitrary commands over the
scsi bus all bets are off.
of course, when the world is nicely structured (as computational
worlds try to be), you can construct layers of objects, such that the
encapsulation of objects in layer n can be guaranteed as long as i
don't touch the objects in layers < n. but even this has limits;
consider the case in which i can turn on a very strong magnetic field
generator that happens to be next to the disk...
--
.mike.graham@comp.lancs.ac.uk (Graham Dean) (01/08/91)
>I think this should go to some other group. >Lance Hmm, how about comp.irrational ? -- Graham -- ************************************************************************** uucp: ...!mcvax!ukc!dcl-cs!graham Department of Computing * arpa: graham%lancs.comp@ucl.cs University of Lancaster * janet: graham@uk.ac.lancs.comp Bailrigg, Lancaster, LA1 4YR, UK *
jimad@microsoft.UUCP (Jim ADCOCK) (01/12/91)
These arguments remind of a large airplane company I worked for 10-12 years ago. Their mathematicians would make sophisticated dynamic models of the airplane's modes of vibrations, "prove" and double-prove the models to be "correct." Then they's build an airplane, we'd measure it, and the measurements would conflict with the models. -- Of course, they claimed the models were correct and the measurements were wrong. Fortunately, most of the planes are good enough, most of the time, to stay in the air. Most customers have a successful flight, and find the planes "perfectly satisfactory" in meeting their flying needs. The occasionally customer [or their heirs] are sorely disappointed, however. The same seems to be true of most good software. Most of the time it works "perfectly well" for most of the customers. For the occasional customer it fails miserably. Take the example of some well known windowing systems. For most people, they work perfectly satisfactory. For me, they work almost not at all -- I'm not at all comfortable with the delay in their visual response -- it really throws me off, the colors are too harsh for my eyes, the esthetics of the industrial designs of the ikons, etc, I consider ludicrous.... As an engineer, I don't see how one "proves" these kinds of issues. The "prover" types will just say, "write me a spec, and I'll see if it passes or not." I claim such a spec, whether passed nor failed, does nothing to improve the quality of the product. I think one would do better to spend one's time and effort to find out what percentage of your customers don't have a successful flight -- and what you can do to improve the situation for them. Concentrate your efforts on what's wrong, not what you can prove is right. Pick the three things that bother customers most, fix them, then repeat the process.
adams@aar.alcatel-alsthom.fr (Drew Adams) (01/14/91)
In article <2491@motcsd.csd.mot.com> lance@motcsd.csd.mot.com (lance.norskog) writes: >jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) writes: > >Here's another meaty subject. Programmers are not taught to be engineers. >Programmers are taught to be poets. An engineer are trained to design >something over and over again before building it, to be sure it's >absolutely correct. What makes you think that poets don't design poems over and over again, to be sure they are absolutely correct, before publishing them? And with respect to other forms of literature, I believe that poets are at least as concerned as other writers with finding `le mot juste', and generally more so. The criteria for determining the appropriateness of different words, phrases and other constructions is different in these different disciplines (programming, specifying, writing fiction, writing non-fiction prose, writing poetry), but in all of them the search for appropriate forms is important. I also believe that it would be an error to assume that all of a poet's criteria for determining such appropriateness are based on subjective intuition. Programs are not poems, but I'm not so sure that training in critically reading and writing poetry would hinder, rather than help, a programmer to develop good programming skills. -- Drew ADAMS: adams@aar.alcatel-alsthom.fr Tel. +33 (1) 64.49.11.54 ALCATEL ALSTHOM Recherche, Route de Nozay, 91460 MARCOUSSIS, FRANCE
objtch@extro.ucc.su.oz.au (Peter Goodall) (01/15/91)
adams@aar.alcatel-alsthom.fr (Drew Adams) writes: >In article <2491@motcsd.csd.mot.com> lance@motcsd.csd.mot.com (lance.norskog) writes: >>jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) writes: >> >>Here's another meaty subject. Programmers are not taught to be engineers. >>Programmers are taught to be poets. An engineer are trained to design >>something over and over again before building it, to be sure it's >>absolutely correct. >What makes you think that poets don't design poems over and over >again, to be sure they are absolutely correct, before publishing them? Although it may not be obvious, I recently read a set of great lecture notes from a course at Stanford on Mathematical Writing given by Donald Knuth. He, or one of his guest lecturers quoted a poet or writer as saying words to the effect of: "you don't ever finish a poem, you just give up on it". Sounds a lot like software to me! >And with respect to other forms of literature, I believe that poets >are at least as concerned as other writers with finding `le mot >juste', and generally more so. >The criteria for determining the appropriateness of different words, >phrases and other constructions is different in these different >disciplines (programming, specifying, writing fiction, writing >non-fiction prose, writing poetry), but in all of them the search for >appropriate forms is important. >I also believe that it would be an error to assume that all of a >poet's criteria for determining such appropriateness are based on >subjective intuition. >Programs are not poems, but I'm not so sure that training in >critically reading and writing poetry would hinder, rather than help, >a programmer to develop good programming skills. Everyone get a copy of Knuth's Course notes. The document is Mathematical Writing by D.E. Knuth, T. Larrabee, and P.M. Roberts The course is/was CS 209. We found a copy in Sydney University library. >-- >Drew ADAMS: adams@aar.alcatel-alsthom.fr Tel. +33 (1) 64.49.11.54 > ALCATEL ALSTHOM Recherche, Route de Nozay, 91460 MARCOUSSIS, FRANCE ---------------------------- Peter Goodall Smalltalk Systems Consultant ObjecTech P/L 162 Burns Bay Rd, LANE COVE , NSW, AUSTRALIA objtch@extro.ucc.su.oz.au
a_dent@fennel.cc.uwa.oz.au (01/16/91)
adams@aar.alcatel-alsthom.fr (Drew Adams) writes: >In article <2491@motcsd.csd.mot.com> lance@motcsd.csd.mot.com (lance.norskog) writes: >>jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) writes: >> >>Here's another meaty subject. Programmers are not taught to be engineers. >>Programmers are taught to be poets. An engineer are trained to design >>something over and over again before building it, to be sure it's >>absolutely correct. >What makes you think that poets don't design poems over and over >again, to be sure they are absolutely correct, before publishing them? My humble (from a bit of writing, including Creative Writing classes, and a couple of OOP projects) thoughts: Not only does poetry involve at LEAST as much search for precisely the correct language/elegant form of expression, I have found the study of Creative Writing increased my ability to take a fresh look at something. In particular, you learn to develop a viewpoint, document it then look at a situation from another viewpoint. The "staging" of dialogue necessary for writing a prose piece is very similar to walking through an imaginary user's sessions with your program. I am now much better at identifying the objects as perceived by the real-world, rather than the (usually) more abstract objects seen by programmers. The attack you come under in CW workshops is often far more vitriolic and personal than would ever be experienced in "structured walkthroughs" or "peer reviews" :-) Andy Dent A.D. Software phone 09 249 2719 Mac & VAX programmer 94 Bermuda Dve, Ballajura a_dent@fennel.cc.uwa.oz Western Australia 6066 a_dent@fennel.cc.uwa.oz.AU (international)
proberts@Neon.Stanford.EDU (Paul Roberts) (01/22/91)
In article <9588:Jan1703:40:1791@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >In article <objtch.663883817@extro> objtch@extro.ucc.su.oz.au (Peter Goodall) writes: >> >> Everyone get a copy of Knuth's Course notes. The document is: >> >> Mathematical Writing >> by >> D.E. Knuth, T. Larrabee, and P.M. Roberts >> The course is/was CS 209. > > It's been published in the MAA (that's the Mathematical Association > of America) lecture notes series. About $10.00 and well worth it. > > ---Dan Marvelous book. Easily worth ten times the price. Buy several copies, and send money direct to the authors! :-)
proberts@Neon.Stanford.EDU (Paul Roberts) (01/29/91)
Someone asked me to post an address from which to order "Mathematical Writing".
It's available in three different incarnations:
(1) As a Stanford University, Computer Science Department Tech Report No.
STAN-CS-88-1193. I believe these reports cost $5 each a few years ago,
inflation may have taken some toll since then. The person to contact is
Julie Baldwin, baldwin@cs.stanford.edu, (415) 723 4776 (MWF 8:30-11:30 PST)
(2) As a paperback from the Mathematical Association of America.
'Fraid I don't have an address for them. I think it costs around $12.
(3) In Japanese, with photographs of the authors and scenic spots around
Stanford, from Kyoritsu Shuppan Co. Ltd. 6-19, Kohinata 4 chome
Bunkyo-ku / Tokyo 112 Japan. I don't know what the mail order deal,
if any, is with them.
If you want only photographs of the authors, send me mail and we'll see
what we can do. :-)