Subj : Writable source equals Reusable source
To   : comp.programming
From : James Dow Allen
Date : Thu Aug 18 2005 02:24 am

In earlier threads I've tried to espouse a key idea:

  Modifying Flexible Source-Code is the Key to Reusability

Perhaps I should rephrase this as

  Source = Writable Source = Reusable Source = Force

     *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *

We need a specific programming task as an example for discussion.

Hash table management has several advantages as such an example:
  -- hash tables are ubiquitous (especially in software
     optimized for speed).
  -- hash tables give a better example than, say, list primitives,
     which are not complicated enough for useful discussion or
     for important economic return due to reusability
  -- hash tables give an easier example than, say, text
     presentation, which has too many modes and modalities for
     ease of discussion or reusability.
  -- in my own experience, coding often involves standard library
     routines (eg. random(), qsort()), cuts-and-pastes and
     writes-from-scratch.  But with hash table management, the
     use of flexible reusable software becomes compelling.

As explained in previous threads, the two widely espoused
hash table managers (Gnu hsearch() and Chuck's hashlib)
are often inadequate for my needs.  I do cheerfully stipulate
that Chuck's is preferable to Gnu's hsearch().

     *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *

When I was first exposed to Unix wizards I was impressed
with some of their magical powers.  Soon I realized they
were making a copy of standard BSD sources and modifying
them, thereby producing custom software quickly.

The key point is that the object files were not the reusable
components; instead modifying the source files for reuse
was the key for rapid development.

This is in stark contrast to conventional thinking which seeks
a ``full-featured'' routine with unchanging source code.
In my hash-table manager -- HashTab (tm) -- I ``have my cake and
eat it too'' since the changing parts of the routine are isolated
in a header file, and most of the code doesn't change.

     *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *
Referring to
       http://www.recmath.com/contest/fullstandings.php

This advantage was brought home again in the latest Al Zimmermann
Programming Contest, where it is convenient to maintain a record
(hash table) of numbers previously encountered within a grid
under construction.  In my solution any hash entry will be in one
of the following states:
	* empty
	* composite
	* composite, pseudo-prime
	* prime not occurring in current grid
	* prime occurring 1, 2, ..., 32767 times

Primes occurring must be maintained for my algorithm
to be valid, but all other entries can be silently
discarded to avoid table growth (though composite
pseudo-primes should be retained for performance).

If I'd been using either of the two widely espoused
solutions (Gnu hsearch, or the superior Chuck's hash)
I suppose I'd have been puzzled briefly, then finessed
the issue, or written hash-from-scratch.  Having been
there before many times, I had my own reusable HashTab
and as usual it was trivial to modify.

I'm sure Chuck would have been happy and competent to hack
his code to support "soft entries", but what if he'd been
on vacation in Tahiti?

     *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *

Regarding the present Al Zimmermann Programming Contest,
the details of the hash table management may not be of
great importance.  An algorithmic approach which can be
inferred from the above discussion *is* important,
and some contestants may have overlooked it.

I am cunningly divulging this idea now, early enough so
that other contestants may choose to modify their algorithms,
but late enough so that such modifications will turn out
to be a net loss of time.

James Dow Allen

.