NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/lang/misc/4050

Text File | 1992-12-16 | 12.1 KB | 223 lines

Newsgroups: comp.lang.misc
Path: sparky!uunet!cis.ohio-state.edu!sample.eng.ohio-state.edu!purdue!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
From: [e-mail] (Herman Rubin)
Subject: Re: Safety.  Was: Re: Pointers
Message-ID: <[e-mail]>
Sender: [e-mail] (USENET News)
Organization: Purdue University Statistics Department
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 16 Dec 1992 18:37:15 GMT
Lines: 211

In article <[e-mail]> [e-mail] (Mark C. Carroll) writes:
>In article <[e-mail]> [e-mail] (Herman Rubin) writes:
>]In article <[e-mail]> [e-mail] (Wayne Throop) writes:
>]]Again, these points are so simple and so clear that it is
>]]remarkable indeed to have anyone capable of reading and writing
>]]disagree with them as Herman has.   And so I remark upon it.

>]]] This is a chicken-and-egg phenomenon.  Most software development does
>]]] not do certain things because the languages, compilers, and the training
>]]] of the programmers does not mention them.

>]]That doesn't answer the question.  Herman specifically requested that
>]]students be exposed to situations where code would "really crawl" unless
>]]heroic and often architecture-specific measures are used to optimize it.
>]]Such cases are extremely rare, whether or not you believe in a catch-22
>]]deadlock between hardware features and language features, or between
>]]developer capabilities and language features.

>]If the actual code is not used, this may be difficult, but even the
>]initial idea that a computer manipulates objects, and that how it does
>]this, and what objects it manipulates, are important.  But the idea of
>]bit-twiddling, etc., seems to have been "obvious" to the early people
>]in computing, and the use of binary in the mathematical literature
>]before that time was extremely small.

>The idea of bit-twiddling was obvious to the early people in
>computing. But then, the problems of programming weren't very clearly
>understood by them. The idea of a writing a program which required
>hundreds of thousands of lines of machine code was almost beyond their
>imagination, and the problems caused by trying to write, understand,
>debig, and maintain such programs were completely unknown to them.

It is true that they did not envision such large machine programs.  Maybe
they were right about it; too often one is confronted with a "package"
which has a few wanted things, lots of items about which one does not
care, and a fair number of supposedly "user friendly" gadgets, which
are often quite "user inimical."

But the types of operations, etc., required do not change merely because
one has lots of them.  Bits are twiddled because some useful operations
require twiddling bits.  Virtually all branches are binary, with a few
ternary such as sign.

>Things have changed. We've learned a lot about programming since then,
>and we've discovered problems that they wouldn't have dreamed of. The
>solutions to their problems aren't necessarily the solutions to ours.
>What was natural to them, isn't necessarily natural to us.

>]]] Unlearning
>]]] provides major obstacles for students in mathematics and statistics, and
>]]] I see no good reason why CS and programming languages should be any
>]]] different in this matter.

>]]Precisely my point.  CS students under Herman's regime would have
>]]much to unlearn before they could read, write, or even think about
>]]portable, maintainable software.  These issues may not be important
>]]to Herman, but Herman is the exception.

>]They would have to unlearn nothing.  Starting out with the idea that
>]there is a large variety of objects, and that machines operate on them
>]in various ways, WILL cause them to question why the languages place
>]obstacles in their use.

>They would have to unlearn a *lot*.

>Good programming almost never requires bit-twiddling. It does require
>clarity, modularity, documentation. A good programmer worries about
>how difficult the code s/he writes will be to understand and maintain.
>In general, the maintainability of the code is by far the most
>important concern. Most of the time (virtually all of the time), the
>speed of the code generated by the compiler is more than adequate, and
>any gains to be made by adding bit-twiddling into the programming will
>be more than outwieghed by the additional difficulty in understanding
>and maintaining the code that takes advantage of them.

Nothing you have stated here is new.  Unfortunately, much of what is done
now is the opposite of modular.  We have these massive operating systems
which do millions of things, and certainly the user can do nothing about
separating them most of the time.  So we impose restrictions like object
files have to have their names end in .o, C source files in .c, etc.  This
is NOT modular, it is the reverse of it.  We have moved from 5 or 6 bits/
character to 8, and few systems allow the direct reading and writing of
these 8-bit characters.

The speed generated by the compiler is only adequate if the facilities
are underused.  Now in many cases, this is not unusual.  It is not often
that the file management mechanism has to be quick in locating files.
And interactive editors do not have to be faster than the typist, EXCEPT
that a shared computer can have many typists on at the same time.  I have
often had to wait for editor response because of system load; doubling the
speed of the executing code would often help a lot.

>Most programming doesn't care about the internal representations of
>its information. In most cases, *it doesn't matter*. For example, I'm
>writing a program that does a graphical simulation of a network
>protocol. I'm not worried about speed, because I've already got to
>slow down the execution of my system to let a human being follow it.
>What I am worried about is *correctness* and *maintainability*. 6
>weeks from now, I'll be done with this project, and some other poor
>schmoe is going to have to take it over, and continue work on it. When
>that guy gets hold of it, it's absolutely crucial that
>    (a) my code be understandable, so that he can expand on it
>    (b) my code be correct, so that when he tries to expand it, he isn't
>      forced to waste time discovering my bugs;
>and (c) my code be *clean*, so that when he extends it, my code doesn't
>      break his, and his code doesn't break mine.
>
My code needs to have the same properties, but I must assume that the
person maintaining my code understands enough of the underlying mathematics
to know why various things are there.  This can vary from elementary algebra
to graduate material.  Also, I do worry about the interface, and that is one
reason why I feel that pointers, or a darn good substitute for them, is
readily available.

In the pre-Unix systems I used, the interfacing problem was usually fairly
easy.  This was not always the case, and interfacing the two calling sequences
on the CDC6x00 often required tweaking assembler code.  But I had no problem
with names on that system; the name that somebody else gave to a program,
module, entry point, etc., was readily apparent, and it also was relatively
easy to edit if necessary.  Try doing this on the current systems, with all
their introduction of underscores.  The pre-Unix systems were reasonably well
designed to use separate compilation, and the transfer of binary modules.

All this was before the "modern" programming era.

>]]] The student who takes a typical cookbook mathematics course seems to
>]]] be farther away from eventually understanding than the one who starts
>]]] out with the concepts and theory.

>]]But the concepts of and theory of mathematics do not have much to do
>]]with the bit-bumming he recommends early exposure to, so Herman's point
>]]is obscure in the extreme.

>]The bit operations are just the binary version of the "standard" decimal
>]operations, and are by no means esoteric, except in the minds of those
>]who would have people grow up ignorant of them.  The goto-laden code I
>]posted was obtained from consideration of how to efficiently use "coin
>]tosses", or other sources of random bits, to produce exponential random
>]variables, and this topic is by no means of recent origin.  Base 2 is
>]useful because it is useful, and not because of arcane considerations.

>The bit operations *are* esoteric, because the bit representations are
>generally esoteric. In most programs, the programmer writes code to
>deal with *integers*, not 16bit 2s complement quantities. It's true
>that the concept the programmer wants to deal with may get represented
>in the machine by 16bit 2s complement quantities, but for the purposes
>of the program being written, it doesn't matter. To go back to the
>example of my current project, if I shifted to a machine which used
>64bit 1s complement numbers instead of 32bit 2s complement, it
>wouldn't affect my code a whit.

In that case, it means that you do not have to handle numbers whose
magnitude is greater than 2^15 - 1 = 32767.  And except for number
theorists, who damn the current languages as much as I do, those
doing numerical mathematics are concerned at least 99% of the time
with non-integers, except for indices and exponents.  But except
for Fortran, these are not well handled, anyhow.

They are no more esoteric than decimal representations.  The importance
of the "Arabic" numerals was not that they changed computation; in fact,
they did not change computation much, if any.  But they provided a
simpler notation.  Interestingly, the Babylonian system, using base
60, was quite similar.

The use of truncated decimal expansions was relatively recent.  Somewhat
older, going back to the latter part of the Hellenistic period, is the
same type of sexagesimal notation for numbers in the unit interval.

From your statements, I feel it is safe to conclude that numerical computation
is not an important part of what you do--at least numerical computation
involving numbers of much precision.  A quite significant part of the
computation being done is that of good numerical computation.  Now Fortran
was originally intended to be a highly limited language, but Algol was not.
However, a major weakness of Algol was that it did not recognize that the
hardware counted.  If the built-in precision is inadequate, any machine-
independent multiple precision code MUST run slower by a substantial factor.


>It's true that in *your* problem domain, these things matter. But your
>domain is one, small, narrow niche. The overwhelming majority of us
>who program don't share your concerns - we have our own worries, which
>don't matter to you. But that doesn't mean that we're imcompetent or
>negligent - the problems we're solving are the problems that need to
>be solved for the work done by the largest number of people.

So you are saying that numerical analysis is unimportant.  That is the
only conclusion I can draw from your statements.  This agrees with the
conclusions which others have drawn about what is going on in computer
software and hardware.

>As I've said before, you're *terribly* ignorant about computer
>science. You don't understand what problems we're trying to solve, and
>you don't care. That's all right - you have your own work to do. But
>so do we. We don't tell you what's wrong with the way you do
>statistics - we're far too ignorant of statistics to be able to
>intelligently comment on your methods. But equally - you're *far* to
>ignorant of computer science, programming languages, and compilers to
>be able to intelligently comment on ours.

If someone comes to me with a statistical problem and wants to know how
to solve it with the "standard" tools provided, quite often I have to
get the problem carefully formulated (usually the client has no idea
what the assumptions being made are), and much of the time I have to
invent a new procedure.  Much of the time this new procedure can be
widely used; some of the time it cannot.  The inventing of new procedures
IS the analog of bit twiddling, as you call it.
--
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: [phone]
[e-mail] (Internet, bitnet)
{purdue,pur-ee}!snap.stat!hrubin(UUCP)