🚀 go-pugleaf

In article <724478076@sheol.UUCP> throopw@sheol.UUCP (Wayne Throop) writes:
>:: I have not seen any posting in which Herman explains *why* he does not
>:: consider unions an adequate way to specify type punning, [...]

			......................

>: If a hardware operation, or even a "natural" operation which is somewhat
>: more complicated, is not in the language, the language is excessively 
>: weak if it cannot be adjoined so as to take into account hardware 
>: capability.  The only language I know which has this operation explicitly
>: is Galaxy. 

>"This operation" (namely, type punning) IS in C and Ada.  Herman just
>objects to the "suggestion" of assignment semantics.  As I recall, PL/I
>also had type punning.  And finally, aren't both Ada and PL/I's type
>punning capabilities value-based rather than assignment-based? (I don't
>have my manuals on those two to hand...)

What should be there for type punning is of the form

	a = use(b),

where a is an arbitrary variable and b an arbitrary expreesion,
and also of the form 

	use_double(c,d)

where, for example, c and d would be 32-bit objects and double is 64-bit.

Probably simpler notation should even be found.

			...............

>Herman is apparently seriously claiming that

>      g(0xABCD)

>is less clumsy and conveys more information than

>      g(iasf(0xABCD))

>It is essentially impossible to take Herman seriously on this point,
>since it is quite obvious that the second case better conveys the
>intention.  The first case that Herman claims to prefer actively
>CONCEALS the intention.

>Note well, I said "the notation at the use point".  And even if I
>hadn't, the definition of the iasf function better conveys intent
>than actively lying to the compiler.

I have never seen iasf before.  But it would be better written as
asf, but is asf "as floating" or "as fixed"; the idea is that the 
ompiler does not look at how things got there, except to find them. 
But I am more interested in this for variables than for constants,
although it is often needed at the present time for constants.

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

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

>Anybody who's been exposed to Lisp and/or PL/I, to name just two
>examples.  Since Herman asks about those having had "advanced" courses,
>I'd say virtually 100%.  Well...  maybe as few as 90%. 

>And if you're really talking mathematics, you're probably dealing
>with Mathematica or equivalent notations anyhow, not imperitive
>algol-family programming languages.

I was NOT talking about these types from mathematical programming
languages, but from the standpoint of mathematics.  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.

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

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

In the 1950s and 1960s, there was still discussion about whether computers
should be binary or decimal.  The reasoning behind binary has almost 
disappeared now, but it was based on computational convenience.  I could
have posted the corresponding code for random digits, but it would have
been far more complicated and less efficient; tests are still mostly done
as 0-1.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@snap.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!snap.stat!hrubin(UUCP)