[comp.lang.misc] 64 bits--why stop there?

cik@l.cc.purdue.edu (Herman Rubin) (09/03/90)

In article <1990Sep2.201943.3670@rice.edu>, preston@titan.rice.edu (Preston Briggs) writes:

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

> If all you need is to find the smallest element in an array,
> you don't bother building a quicksort.  If you need to run
> C fast, you don't support bit, pair, or nibble addressing.  If you
> intend to run Fortran, you don't bother with 8 or 16 bit addressing
> either.

But what if your problem is best done by a combination of these?

> Of course, this kind of thinking is the sort Rubin rails against.
> Languages are (often) designed to run on available machine and then
> later machines are designed to supprot the languages *and nothing else*.
> This leads to certain ideas or paradigms being unsupported.

The problem is clearly expressed.

> I guess I'd like to see high-level expressions of the problems that aren't
> well supported.  If an adequate form of expression can be invented (this
> is probably hard -- good notation is very hard), then we can see about
> supporting it on different machines.

If one wants to get a notation which is in some sense optimal, this is very
hard indeed.  But by having the language fully extensible, including operator
symbols, etc., this would not be difficult.  This happens all the time in
mathematics and other sciences.  The one creating the expresson form suggests
a syntax, and usage decides.  It is not that difficult to have different
expressions used by different authors more many years.

> For example, a "typical Rubin problem" (based on limit observations)
> is usually expressed in terms of random bit strings.
> But what's really going on?  Can we get a little more abstract,
> away from the "bit string" part.  How about "a stream of random
> boolean values" or something.  As far as implementation, why use 
> a bit string?  Why not a linked list or some combination of
> linked list and array.  There are a lot of choices of structure that
> significantly influence the algorithmic complexity of solutions.

Random boolean values would be just as good as random bit strings.  On
all vector processors about which I know, bit strings are used as such,
although in many they have to be aligned in registers.  It is not at all
difficult to come up with situations where the bit strings will not be
aligned in memory.

These are not the only types of hardware inadequacy I have pointed out.
But the procedures which use these operations arise quite naturally in
methods of generating random variables, processing (other than copying)
only a few bits.

Not a single one of the hardware suggestions I have made was made for the
purpose of coming up with esoteric hardware.  Every one arose from a 
"natural" problem.  I suggest that others do the same. and that an attempt
be made to incorporate them, rather than dismiss them as "why do we need
such things."
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet)	{purdue,pur-ee}!l.cc!cik(UUCP)