Re: Who were the opponents of Lisp?
Xah Lee
m_mom...@yahoo.com (Mario S. Mommer) writes:
«In my experience, writing directly to TeX or anything similar is
asking for trouble unless you are doing simple things. The source is
not all that readable, and the hardcopy looks too good. The result is
that you do not see the mistakes and the holes in the arguments.
Taking a draft on paper and cleaning it up by copying the non-strike-
out to new a paper draft is the only really good way to make sure you
are really really really going over every detail again.»
I agree here.
«My senior year, I chose to write all my papers by hand, starting from
an outline, then rewriting it fleshed out a bit, then rewriting again,
and so on until I had a finished paper, all written longhand. Then
I'd go home and typeset it with LaTeX.»
lol. Writing by pen on paper? That's not a good advice. In fact, it
would be too slow to be workable for me. For me, the ratio of ideas i
need to put out vs the speed i can do with pen is not good, resulting
in many thoughts lost in the hand laboring.
It is important to make writing a separate process from typesetting
and or the technology used in writing. So, when i write math, or in
general other subjects, the first draft i just quickly put out all my
main ideas quickly, then, edit, format, typeset, and prettify.
For example, in the edit process, if the text is technical tutorial or
exposition, i reduce difficult word, shorten sentences, make steps
explicit, make statement precise, add code samples, more research for
code snippets, references, etc.
If the writing is essay in literary context, i may for example add
more fancy words or literary devices.
Actually, just yesterday i wrote:
• The Writing Style on XahLee.org
http://xahlee.org/Periodic_dosage_dir/bangu/xah_style.html
it describes the writing style i follow.
On Apr 19, 4:40 am, r...@rpw3.org (Rob Warnock) wrote:
Robert Uhl <eadmun...@NOSPAMgmail.com> wrote:
> As Halmos said in his classic little essay:
>
> http://www.maths.ed.ac.uk/pg/data/halmosw.pdf [3.3 MB, 30 pages]
> How to write mathematics
> P. R. Halmos
> ...
> 6. Write in Spirals
> The best way to start writing, perhaps the only way, is to write
> on the spiral plan. According to the spiral plan the chapters get
> written in the order 1, 2, 1, 2, 3, 1, 2, 3, 4, etc. You think you
> know how to write Chapter 1, but after you have done it and gone
> on to Chapter 2, you'll realize that you could have done a better
> job on Chapter 2 if you had done Chapter 1 differently. There is
> no help for it but to go back, do Chapter 1 again differently, do a
> better job on Chapter 2, and then dive into Chapter 3. And of course
> you know what will happen: Chapter 3 will show up the weaknesses of
> Chapters 1 and 2, and there is no help for it... etc., etc., etc.
>
> I especially have always liked this bit:
>
> When you come to rewrite, however, and however often that may
> be necessary, do not edit but rewrite. It is tempting to use a
> red pencil to indicate insertions, deletions, and permutations,
> but in my experience it leads to catastrophic blunders. Against
> human impatience, and against the all too human partiality everyone
> feels toward his own words, a red pencil is much too feeble a weapon.
> [...] Rewrite means write again -- every word.
Can't say i support this idea at all. Such “spiral” method result in
never finishing anything.
with this context, i'd recommend rather to actually complete a first
draft of the whole, first. Then, come back and revise. The gist being
that you want to get it done first, and never fuzz over on what you've
already written.
knowledge and learning is a life long process. One always learns more
and more. I'd say most authors would write a better book if they can
do it again.
... which clown is it that gave this “spiral” shit? So i looked up:
http://en.wikipedia.org/wiki/P._R._Halmos
ok, a known mathematician. O well. Know that tremendously many
specialized experts in history have given outrageously stupid advices
in areas outside of their expertise. Not saying that his “spiral”
method is such example... since all i know of it is the quoted
paragraph here. Note also that Knuth has published a booklet (or so)
about technical writing. (i think i scan'd it in early 1990s) Cant't
say i was impressed in anyway by Knuth's writings... though it's long
ago and i don't remember what it says, but usually i'd remember
something about it if it made a impression on me.
Xah
∑ http://xahlee.org/
☄
Don Phillipson
> As Halmos said in his classic little essay:
>
> http://www.maths.ed.ac.uk/pg/data/halmosw.pdf [3.3 MB, 30 pages]
> How to write mathematics
> P. R. Halmos
> ...
> 6. Write in Spirals
> The best way to start writing, perhaps the only way, is to write
> on the spiral plan. According to the spiral plan the chapters get
> written in the order 1, 2, 1, 2, 3, 1, 2, 3, 4, etc. You think you
> know how to write Chapter 1, but after you have done it and gone
> on to Chapter 2, you'll realize that you could have done a better
> job on Chapter 2 if you had done Chapter 1 differently. There is
> no help for it but to go back, do Chapter 1 again differently, do a
> better job on Chapter 2, and then dive into Chapter 3. And of course
> you know what will happen: Chapter 3 will show up the weaknesses of
> Chapters 1 and 2, and there is no help for it... etc., etc., etc.
This is the method recommended by some professional
authors (Somerset Maugham and P.D. James come to mind)
who say every day's work should begin by rereading at least
the previous week's output.
> I especially have always liked this bit:
>
> When you come to rewrite, however, and however often that may
> be necessary, do not edit but rewrite. It is tempting to use a
> red pencil to indicate insertions, deletions, and permutations,
> but in my experience it leads to catastrophic blunders. Against
> human impatience, and against the all too human partiality everyone
> feels toward his own words, a red pencil is much too feeble a weapon.
> [...] Rewrite means write again -- every word.
For literature (not mathematics) this is the opposite of most
well-regarded advice. The best general maxim is to shorten
wherever possible, removing words or whole sentences. (On
computer, it takes no time to restore them if the writer has
second thoughts.) It seems a mistake to plan to rewrite every
word regardless of differences between the first, second and third
class qualities of what you wrote earlier.
--
Don Phillipson
Carlsbad Springs
(Ottawa, Canada)
Peter Moylan
papers, lecture notes, etc. - and I started doing that before the days
of word processors, when cut-and-paste had a much more literal meaning.
Any correction was likely to mean that the typist had to redo an entire
page.
Whether it was for that reason, or some other, I don't know; but I
adopted a rule that said "Don't revise; get it right the first time".
This has served me well over the years. I do revise things like e-mails,
which is perhaps a little silly. For serious writing, I write once, and
that is the final result. In my experience, revisions only lower the
quality.
Now and then, of course, what I write is complete junk. I don't revise
that either. It goes straight into the garbage junk. I then either
rewrite from scratch, or abandon the project.
(A lot of my writing was heavily mathematical, too. In that case I did
revise, in a sense, but not in the way Halmos meant. Instead, I used a
method of successive refinement, where I started with an outline and
then gradually filled in the details. You have to do that if you want to
present theorems but haven't yet figured out the proofs.)
Here's an interesting example from my teaching computer programming.
Programmers typically expect to have to revise over and over, with
numerous recompilations as errors are revealed. Once, though, I set a
programming assignment with the rule "You only get one chance to have it
compile and run correctly." (This was in the days of punched cards,
where the turnaround was one compilation per day.) Remarkably, about 70%
of the class turned in a working program. Since the students knew they
couldn't use trial and error, they took more care to avoid inserting the
errors in the first place.
Modern programming languages, especially the object-oriented ones, seem
to encourage a philosophy of "Let's try this and see whether it works".
That's a big mistake, in my opinion.
--
Peter Moylan, Newcastle, NSW, Australia. http://www.pmoylan.org
For an e-mail address, see my web page.
Adam Funk
> Actually, just yesterday i wrote:
>
> • The Writing Style on XahLee.org
> http://xahlee.org/Periodic_dosage_dir/bangu/xah_style.html
The paragraph on dashes goes against every standard for English that
I've seen. In typeset work, em-dashes should never be spaced
(although I use " --- " for them in plain-text formats such as
USENET), and there is a useful distinction between em- and en-dashes
(the latter are for ranges of numbers, for example). Many British
publishers follow a custom of using spaced en-dashes instead of
em-dashes; I don't like this, but at least they are making the
distinction.
--
Mathematiker sind wie Franzosen: Was man ihnen auch sagt, übersetzen
sie in ihre eigene Sprache, so daß unverzüglich etwas völlig anderes
daraus wird. [Goethe]
Xah Lee
> On 2010-04-20, Xah Lee wrote:
>
> > Actually, just yesterday i wrote:
>
> > • The Writing Style on XahLee.org
> > http://xahlee.org/Periodic_dosage_dir/bangu/xah_style.html
>
> The paragraph on dashes goes against every standard for English that
> I've seen. In typeset work, em-dashes should never be spaced
> (although I use " --- " for them in plain-text formats such as
> USENET), and there is a useful distinction between em- and en-dashes
> (the latter are for ranges of numbers, for example). Many British
> publishers follow a custom of using spaced en-dashes instead of
> em-dashes; I don't like this, but at least they are making the
> distinction.
I think most of your remarks is factually wrong. I was going to be
colorful and say that the logical conclusion is that you haven't seen
much, but, just that most of your remarks is factually wrong.
See, for example, here, on the section on Hyphen and Dashes:
• The Moronicities of Typography
http://xahlee.org/Periodic_dosage_dir/bangu/typography.html
Xah
∑ http://xahlee.org/
☄
Pascal J. Bourguignon
> Modern programming languages, especially the object-oriented ones, seem
> to encourage a philosophy of "Let's try this and see whether it works".
> That's a big mistake, in my opinion.
I too would like a more "constructivist" approach to programming, but
unfortunately, with most of the code out there (libraries, etc), you
cannot really expect to be able to use correctly them without trying
them out. (All, really, you would be hard pressed finding one that is
documented well enough, and enough bug free to be able to write a client
working from the first time).
--
__Pascal Bourguignon__
Peter Brooks
>
>
> Here's an interesting example from my teaching computer programming.
> Programmers typically expect to have to revise over and over, with
> numerous recompilations as errors are revealed. Once, though, I set a
> programming assignment with the rule "You only get one chance to have it
> compile and run correctly." (This was in the days of punched cards,
> where the turnaround was one compilation per day.) Remarkably, about 70%
> of the class turned in a working program. Since the students knew they
> couldn't use trial and error, they took more care to avoid inserting the
> errors in the first place.
>
computer at all. We had to write the whole program on coding sheets,
in pencil. The scoring of tests was simple, you started with 100%, any
typo was -1%; the tests ran to about four coding sheets, any logic
error was -3%, the pass rate was 96% and if you failed the weekly
test, two weeks running, you were off the course. They turned out some
amazing programming machines that way.
>
> Modern programming languages, especially the object-oriented ones, seem
> to encourage a philosophy of "Let's try this and see whether it works".
> That's a big mistake, in my opinion.
>
My more human experience was with Pascal. With that I found that once
I got the compile to run through, there were seldom any logic errors -
unlike FORTRAN or assembler that would compile first time, but be
riddled with them.
Xah Lee
> But you don't write in-depth technical stuff. You write in a
> blogger-tutorial style.
humm... that's a reasonable critique. Am trying to think hard, of all
my hyperbole and boasts of my writing skills and knowledge, i don't
think i have written a coherent academic quality work of more than,
say, 50k words. Well, actually, my special plane curves, my wall paper
group exposition, my emacs tutorial, come close, or very close. In
fact, thinking about these works, it simply thwarts your claim. They
are rather in-depth and not just blogging styled
tutorial. The plane curves and emacs each are book sized too, much
more than 50k words. Especially the math works, are cited in more than
ten academic journals and text books.
what am thinking more to myself, is that i don't think i have wrote
some none technical subjects that's substantial and coherently
sizable. All i have is pretty much a collection of a hundred or 2
disparate short essays that are more or less so-called creative
writings, mostly academically classified as rant style of social
commentary.
But here again, what am actually doing is close to introspection of
self-worth — a flaw of mine. All things considered, of my published
writings, with as much indifference as possible, i'd say they are more
worth than say lifetime output of more than 90% of today's PhDs.
> The following are from your article:
> > Do not use a "and" for the last item in a sequence of things, unless
> > it is too odd. For example, write "My favorite fruits are peach,
> > banana, cherry", not "My favorite fruits are peach, banana, and
> > cherry".
> > The article "an" is always written as "a".
>
> Which clown invents their own grammar? It makes your stuff just awkward
> to read.
Awkwardness is a point of view, young man.
Don't you find Shakespeare awkward to read?
Don't you find Chinese awkward to read?
Do you find one cuming or one Finnegans awkward to read?
have you thought about the reasons why? If you put your mind into
this, you could, write a 3 thousands words essay about this topic. For
example, here's some tips to start your essay. Classify the reasons.
Give example of each. Quote the part of literature for each. Define
what is meant by “awkward to read”. And, unavoidably, you probably
have to philosophize about the audience. Depending on where you want
to go, your essay can turn into classification of audiences, research
report on english styles, nature and character of works from
recognized stylists, definition of english styles, history of english
styles, survey of world's styles by region... etc. (the work in this
can become years long, tantamount to a phD's thesis.)
After which, you'll have a reasonable workout on this matter, then
perhaps you'll see, my point of view.
alternatively, you can just read more of me.
• To An Or Not To An
http://xahlee.org/Periodic_dosage_dir/bangu/an.html
• On the Postposition of Conjunction in Penultimate Position of a
Sequence
http://xahlee.org/Periodic_dosage_dir/t2/1_2_and_3.html
Xah
∑ http://xahlee.org/
☄
the Omrud
> Here's an interesting example from my teaching computer programming.
> Programmers typically expect to have to revise over and over, with
> numerous recompilations as errors are revealed. Once, though, I set a
> programming assignment with the rule "You only get one chance to have it
> compile and run correctly." (This was in the days of punched cards,
> where the turnaround was one compilation per day.) Remarkably, about 70%
> of the class turned in a working program. Since the students knew they
> couldn't use trial and error, they took more care to avoid inserting the
> errors in the first place.
When studying Comupter Science in the 70s, we were allowed (I think)
three compilation and testing runs for our marked assignments. Just as
you describe, this was with punched cards and slow turnaround. But one
could obtain favours from the punch girls by befriending them. I
should mention that the "girls" were mostly middle aged women, but they
were often ignored by the department members and looked favourably on
anybody who would stop and chat.
--
David
Adam Funk
> On Apr 21, 5:00 am, Adam Funk <a24...@ducksburg.com> wrote:
>> On 2010-04-20, Xah Lee wrote:
>>
>> > Actually, just yesterday i wrote:
>>
>> > • The Writing Style on XahLee.org
>> > http://xahlee.org/Periodic_dosage_dir/bangu/xah_style.html
>>
>> The paragraph on dashes goes against every standard for English that
>> I've seen. In typeset work, em-dashes should never be spaced
>> (although I use " --- " for them in plain-text formats such as
>> USENET), and there is a useful distinction between em- and en-dashes
>> (the latter are for ranges of numbers, for example). Many British
>> publishers follow a custom of using spaced en-dashes instead of
>> em-dashes; I don't like this, but at least they are making the
>> distinction.
>
> I think most of your remarks is factually wrong. I was going to be
> colorful and say that the logical conclusion is that you haven't seen
> much, but, just that most of your remarks is factually wrong.
I'm fairly sure the factual claims in what I wrote are correct. The
opinion parts are where we disagree, ...
> See, for example, here, on the section on Hyphen and Dashes:
>
> • The Moronicities of Typography
> http://xahlee.org/Periodic_dosage_dir/bangu/typography.html
...because I see you're developing your own standards, as well as your
own version of English ("and", "a"/"an", for example).
--
I don't know what they have to say
It makes no difference anyway;
Whatever it is, I'm against it! [Prof. Wagstaff]
Adam Funk
That reminds me of this explanation of why MIT switched from Scheme to
Python for the 1st-year EE & CS curriculum:
In 1980, computer engineering was based on starting with
clearly-defined things (primitives or small programs) and using
them to build larger things that ended up being clearly-defined.
Composition of these fragments was the name of the game.
However, nowadays, a real engineer is given a big software library,
with a 300-page manual that's full of errors. He's also given a
robot, whose exact behavior is extremely hard to characterize (what
happens when a wheel slips?). The engineer must learn to perform
scientific experiments to find out how the software and hardware
actually work, at least enough to accomplish the job at hand.
http://danweinreb.org/blog/why-did-mit-switch-from-scheme-to-python
--
Classical Greek lent itself to the promulgation of a rich culture,
indeed, to Western civilization. Computer languages bring us
doorbells that chime with thirty-two tunes, alt.sex.bestiality, and
Tetris clones. (Stoll 1995)
Pascal J. Bourguignon
Anybody wanting to derive his own language should start from another
language than English. I would advise starting from Esperanto...
(I'm answering to your post since I killfiled Xah long ago).
There's no point in fixing something bad when there are already way
better alternatives.
--
__Pascal Bourguignon__
Robin Bignall
[AUE]
When I was a newly-minted IBM SE at a well-known oil company in 1968
there were salaried 'programmers' who took half a dozen tries just to
get a clean COBOL compilation even before they started to check the
logic. People who knew anything about programming were short on the
ground in those days. Two years later, as lead SE in another WKOC, we
put out an advert for trainee programmers (we wanted eight) and got
nearly 4000 legible replies. Everybody wanted to jump on this new
bandwagon, but training opportunities were few. All of the people
with diplomas in 'programming' from expensive, private 'programming
colleges' who responded to that advert failed the IBM aptitude test.
--
Robin
(BrE)
Herts, England
Joe Fineman
> Modern programming languages, especially the object-oriented ones,
> seem to encourage a philosophy of "Let's try this and see whether it
> works". That's a big mistake, in my opinion.
I used to work for a guy whose spaghetti Fortran inspired me to
wisecrack, "The idea is to make it complicated enough to feel pain,
and then punish it till it does what you want". Perhaps we were ahead
of our time.
--
--- Joe Fineman jo...@verizon.net
||: Men have two heads, but only enough blood to operate one at :||
||: a time. :||
Peter Moylan
> Peter Moylan <gro.nalyomp@retep> writes:
>
>> Modern programming languages, especially the object-oriented ones,
>> seem to encourage a philosophy of "Let's try this and see whether it
>> works". That's a big mistake, in my opinion.
>
> I used to work for a guy whose spaghetti Fortran inspired me to
> wisecrack, "The idea is to make it complicated enough to feel pain,
> and then punish it till it does what you want". Perhaps we were ahead
> of our time.
Good old spaghetti Fortran. I was once given a program like that and
asked to translate it into Pascal - not an easy job because it was
packed solid with three-way conditional GOTOs that jumped all over the
place. After several days of analysis, I discovered that the overall
program flow could be described by two nested loops. The outer loop was
executed exactly once, and the inner one was not executed at all.
The original author had no idea that a good chunk of his code did nothing.
the Omrud
GOTO is annoying, but things get really difficult if the programmer has
used the COMEFROM command.
--
David
Peter Duncanson (BrE)
Fortunately sheepdog commands have not infiltrated programming
languages: "come-by", move to the left, and "away", move to the right.
--
Peter Duncanson, UK
(in alt.usage.english)
Peter Duncanson (BrE)
Reverse those directions. "Come-by" is an instruction to the dog to move
clockwise round the flock.
The first webpage I checked seems have the directions wrong.
Xah Lee
> I'm fairly sure the factual claims in what I wrote are correct. The
> opinion parts are where we disagree, ...
The number of recalcitrant donkeys online are amazing. Even after
showing them proof, they insist to the contrary.
lol.
my problem has been how explicit should i be. You see, i refuse to be
too explicit. Like, a chick needn't need to pop her tits out in order
to solicit intercourse. And if the guy still don't get it, the chick
might as well change her mind.
so, at this point, my self-struggle is whether i should define,
EXPLICITLY, a fact we are debating, then, cite references, and insert
many examples EXPLICITLY in the post.
should i??
you see, even if we went to this trouble, agreement still may not
come. Judging from past experience with tech geekers... the problem
than becomes one of interpretation or philosophy. They say, o but
that's not what i meant. Or, change of subject, like, “but there's no
alternative”, or, “but you are just a troll”.
I LOL.
Xah
∑ http://xahlee.org/
☄
CDB
>
[spaghetti Fortran]
>>>
>>> GOTO is annoying, but things get really difficult if the
>>> programmer has used the COMEFROM command.
>>
>> Fortunately sheepdog commands have not infiltrated programming
>> languages: "come-by", move to the left, and "away", move to the
>> right.
>
> Reverse those directions. "Come-by" is an instruction to the dog to
> move clockwise round the flock.
>
> The first webpage I checked seems have the directions wrong.
>
for "go around clockwise" and "turn left" (we go round) and "go around
counterclockwise" and "turn right" (on the side). Having him on leash
helps too. Chows don't have the Collie work ethic, and they are
notoriously independent. Stuff it, Monkey; I'm in charge here.
Mark Brader
> Good old spaghetti Fortran. I was once given a program like that and
> asked to translate it into Pascal - not an easy job because it was
> packed solid with three-way conditional GOTOs that jumped all over the
> place. After several days of analysis, I discovered that the overall
> program flow could be described by two nested loops. The outer loop was
> executed exactly once, and the inner one was not executed at all.
>
> The original author had no idea that a good chunk of his code did nothing.
Now there's superior programming for you. He not only wrote code to
deal with the situation that was possible, but also for one that was
impossible!
:-)
--
Mark Brader, Toronto | "A good programmer is someone who looks both ways
m...@vex.net | before crossing a one-way street." -- Doug Linder
Athel Cornish-Bowden
> Peter Moylan <gro.nalyomp@retep> writes:
>
>> Modern programming languages, especially the object-oriented ones,
>> seem to encourage a philosophy of "Let's try this and see whether it
>> works". That's a big mistake, in my opinion.
>
> I used to work for a guy whose spaghetti Fortran inspired me to
> wisecrack, "The idea is to make it complicated enough to feel pain,
> and then punish it till it does what you want". Perhaps we were ahead
> of our time.
I read once that the original Fortran compiler was written in just that
spirit. The programmers couldn't always understand what their assembler
code was going to do, so they found out by experiment and then embodied
the results into the language, with the result that some of the rules
were rather peculiar.
--
athel
russell
<snip>
>
> On Apr 19, 4:40 am, r...@rpw3.org (Rob Warnock) wrote:
> Robert Uhl <eadmun...@NOSPAMgmail.com> wrote:
>
>> As Halmos said in his classic little essay:
>>
>> http://www.maths.ed.ac.uk/pg/data/halmosw.pdf [3.3 MB, 30 pages]
>> How to write mathematics
>> P. R. Halmos
>> ...
>> 6. Write in Spirals
>> The best way to start writing, perhaps the only way, is to write
>> on the spiral plan. According to the spiral plan the chapters get
>> written in the order 1, 2, 1, 2, 3, 1, 2, 3, 4, etc. You think you
>> know how to write Chapter 1, but after you have done it and gone
>> on to Chapter 2, you'll realize that you could have done a better
>> job on Chapter 2 if you had done Chapter 1 differently. There is
>> no help for it but to go back, do Chapter 1 again differently, do a
>> better job on Chapter 2, and then dive into Chapter 3. And of course
>> you know what will happen: Chapter 3 will show up the weaknesses of
>> Chapters 1 and 2, and there is no help for it... etc., etc., etc.
>>
<snip>
No no no, The best way to rewrite, as everybody knows, is to use a
modified tower of Hanoi sequence e.g. (1 2 1 3 1 2 1 4 1 2 1 3 1 2 1)
--russell
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
Mark Brader
> I can match that almost exactly. Around 1975 I needed a routine to
> determine the median of a set of numbers, and was very proud of
> producing about 10 lines of Fortran full of three-way switches and with
> all but one line numbered, with all the numbers referenced. In those
> days I thought writing impenetrable code was a virtue...
Well, so it is -- if that's what your *goal* is.
This reminds me of a passage in "The Elements of Programming Style"
by Brian Kernighan and P.J. Plauger. (This is from the second edition;
the first edition had a very similar program but in PL/I.)
# IF(X .LT. Y) GO TO 30
# IF (Y .LT. Z) GO TO 50
# SMALL = Z
# GO TO 70
# 30 IF (X .LT. Z) GO TO 60
# SMALL = Z
# GO TO 70
# 50 SMALL = Y
# GO TO 70
# 60 SMALL = X
# 70 ...
#
# Ten lines, with four statement numbers and six GOTO's; surely
# *something* is happening. Before reading further, test yourself.
# What does this program do?
#
# The mnemonic SMALL is a giveaway -- the sequence sets SMALL to
# the smallest of X, Y, and Z.
#
# There are a number of ways to do this computation. If our purpose
# is to teach how to compute the minimum, we write
#
# SMALL=X
# IF (Y .LT. SMALL) SMALL = Y
# IF (Z .LT. SMALL) SMALL = Z
#
# which is direct and to the point. Labels and GOTOs are not needed.
# And the generalization to computing the minimum of many elements
# is obvious.
...
# But if we are just trying to get the job done, we use the FORTRAN
# built-in function AMIN1, which computes the minimum of two or more
# floating-point numbers:
#
# SMALL = AMIN1(X,Y,Z)
#
# One line replaces ten. How can code that is an order of magnitude
# too large be considered reliable?
In the same manner, I present:
MEDIAN = X + Y + Z - AMAX1(X,Y,Z) - AMIN1(X,Y,Z)
To be fair, this is subject to rounding errors and may fail totally
if the numbers are grossly different in magnitude. The corresponding
approach is safe with integers, though, unless there is a danger of
overflow. To avoid such issues, you do need to do a series of
comparisons, or use the generalized approach of calling an actual
sort function.
--
Mark Brader | "People tend to assume that things they don't know
Toronto | about are either safe or dangerous or useless,
m...@vex.net | depending on their prejudices." -- Tim Freeman
My text in this article is in the public domain, if you can find it.
Adam Funk
> I can match that almost exactly. Around 1975 I needed a routine to
> determine the median of a set of numbers, and was very proud of
> producing about 10 lines of Fortran full of three-way switches and with
> all but one line numbered, with all the numbers referenced. In those
> days I thought writing impenetrable code was a virtue, but I'm quite
> sure that a year after writing it I wouldn't have been able to analyse
> how it worked (like yours, though, it did.)
I bet that making people re-use their own code is a good way to teach
that inscrutability is not a virtue.
> Since switching to Pascal a
> little over 20 years ago I find I can still understand what I've
> written no matter how long afterwards.
>
> Mind you, the Fortran-Pascal edition of "Numerical Recipes" (Press et
> al., around 1988) showed that is perfectly possible to write
> incomprehensible code in Pascal. All their so-called Pascal examples
> were machine-translated from Fortran, so, not surprisingly, they
> embodied none of the advantages of writing in Pascal.
The standard textbooks in computational linguistics used to include
Gazdar & Mellish's _Natural Language Processing in PROLOG: an
Introduction to Computational Linguistics_ (1989), _Natural Language
Processing in LISP: an Introduction to Computational Linguistics_
(1989), and _Natural Language Processing in POP-11: an Introduction to
Computational Linguistics_ (1989).
I've only used the Prolog one, but AFAICT the others were the same
except for the source code. Although a lot of the same kinds of
people (AI & CL) use Prolog and Lisp, they don't really map neatly to
each other. (I'm not familiar with POP-11.)
--
I put bomb in squirrel's briefcase and who gets blown up? Me!