🚀 go-pugleaf

::: The notation is more clumsy, and definitely does not convey the intention.
:: Herman is apparently seriously claiming that
::       g(0xABCD)
:: is less clumsy and conveys more information than
::       g(iasf(0xABCD))

: From: hrubin@pop.stat.purdue.edu (Herman Rubin)
: Message-ID: <BzCxs6.9oC@mentor.cc.purdue.edu>
: I have never seen iasf before.  

Now we find that Herman proclaimed one notation "less clumsy"
than another WITHOUT EVER LOOKING AT EITHER NOTATION.  Forgive me,
but I really can't see how to carry on an interaction with somebody
who simply shouts down all comers without even listening to what
they say.  But I seldom let such trivial difficulties discourage me.

: But it would be better written as
: asf, but is asf "as floating" or "as fixed"; the idea is that the 
: compiler does not look at how things got there, except to find them. 

Yes, fine, wonderful.  But totally irrelevant.

: But I am more interested in this for variables than for constants,
: although it is often needed at the present time for constants.

If Herman had been paying even the most cursory attention, he
would have seen that the definition I gave for iasf works for
variables just fine.

:: 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. 

This is simply confusing issues of implementation with issues of
notation (and abstraction) yet again.  To focus on the concrete early
and to the exclusion of other material is counterproductive.

Specifically, an early focus on the logical objects that computers
manipulate primitively for reasons of physical design in preference to
focussing on the logical objects that the users wish to manipulate is a
mistake.  I say "is a mistake" because I've encountered lots of folks
who focus in this way as a programming stance, and their code is
invariably more difficult to extend, understand, reuse, and "port",
because the code embodies the computer's concerns instead of the
concerns of the problem it sets out to solve.

Herman gets away with conflating the abstractions of binary notations
with the implementation issues of computer arithmetic, simply because
the two domains overlap.  But most programmers do not have the luxury
to be so sloppy.

::: What proportion of current programmers, even those who have had
::: "advanced" courses, are aware of the important mathematical types of
::: fixed point (NOT integer) and rational?
:: I'd say virtually 100%.  Well...  maybe as few as 90%. 
: I was NOT talking about these types from mathematical programming
: languages, but from the standpoint of mathematics.

Ok, fine.  But the answer is STILL virtually 100%, since these subjects
are treated in elementary and high school.  At least, they were in *my*
elementary and high schools, and still are in those of young folk of my
aquaintance.

: I submit that the number of people who know about rational and
: fixed-point is larger than those who know any programming language, and
: may very well be more than those who know about the floating-point
: kludge.  It very definitely is a kludge mathematically. 

Yes, and all this is covered in elementary courses in numerical
analysis, which was a required course for CS students in my time.
So We've established that the general mathematical notions are taught
early, and that the shortcomings of various attempts to approach these
mathematical notions on computers are routinely taught to CS students.

So, what's the problem?  What about this is Herman proposing to change?

:: 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. 

Yes, exactly so.  They will be focussing on what computers can do
instead of what they want to get done.  Exactly the wrong thing
for them to focus on, and hence they'll have a LOT of unlearning
to do before they can get their head out of worrying about what
the computer can do for them, and start worring about what they
can do with the computer.

:: 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. 

Well, for all practical purposes, the set of "those who would have
people grow up ignorant of [..binary notations..]" is the empty set, 
so Hermans's point is moot on the face of it, as well as being obscure.

But again, the point is  NOT to keep people in ignorance.  It is quite
a perversion of what I have been saying to conclude that.  No, the
problem is one of priorities.  In solving a problem, should one focus
on the accidents of the implementation, or on the essentials of the
abstract model that captures the problem?  Certainly, one must be
*aware* of the characteristics of the implementations available, to one
degree or another.  But I still find placing the primary focus on
accidental features over essential ones very wrong-headed.  Yet this
is what Herman seems to be saying (even if it isn't what he means).
--
Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw