Ein Doppel-Axel in C (2) lsearch, tsearch, hsearch

Transkript

1 Ein Doppel-Axel in C (2) lsearch, tsearch, hsearch Axel-Tobias Schreiner, Universität Ulm Kernighan und Ritchie s fünftes Kapitel 1 ist für jeden C Programmierer natürlich Pflicht. Die Kür besteht bei System V offensichtlich darin, Suchfunktionen nicht mehr selbst zu programmieren, sondern die verschiedenen Lösungen zu diesem Thema aus der Standard-Bücherei korrekt einsetzen zu können. In der letzten Ausgabe der Sprechstunde wurden Beispiele für die Verwendung der Funktionen qsor t() und bsearch() gezeigt; außerdem wurde die lsearch()-familie vorgestellt. Jetzt geht es mit dem üblichen Test weiter einem Programm zur Zählung der Häufigkeit von Worten in einem Text und wir betrachten auch noch die Funktionsfamilien hsearch() und tsearch(). Langsam zählen lsearch() und binary() lsearch() kann man zur Lösung des Häufigkeitsproblems höchstens als abschreckendes Beispiel verwenden. Als Kür für Zeiger eignet es sich aber ganz gut: typedef struct { char * word; int freq; Object; /* ein Wort */ 1...über Zeiger und Vektoren.

2 static Object * table; /* Vektor aller Worte */ static int t, mt; /* aktuelle und maximale Anzahl */ static int cmpw(a, b) register Object * a, * b; /* Worte vergleichen */ { return strcmp(a >word, b >word); static int cmpf(a, b) register Object * a, * b; /* Haeufigkeit vergleichen */ { register int c; return (c = a >freq b >freq)? c : strcmp(a >word, b >word); alpha() { register int i; Qsort(table, t, cmpw); for (i = 0; i < t; ++ i) puts(table[i].word); frequency() { register int i; Qsort(table, t, cmpf); for (i = 0; i < t; ++ i) puts(table[i].word); Da die Worte sicher verschieden lang sind, und da es wahrscheinlich ein paar sehr lange Worte gibt, speichern wir auch die Texte der Worte dynamisch. Die Tabelle mit den Zeigern auf die Worte und den Häufigkeitszählern wird selbstverständlich dynamisch unterhalten. lsearch() sortiert die Tabelle nicht; für die Ausgabe muß 2 deshalb die Tabelle jeweils nach dem richtigen Kriterium sortiert werden. Die 2 Qsor t() ist ein Makro aus der vorigen Ausgabe, der für die richtigen Umwandlungen bei qsor t() sorgt und die Elementgröße selbst berechnet.

3 ernsthafte Arbeit leistet count(), denn hier muß vor allem der Vektor table[] dynamisch verwaltet werden: count(word) register char * word; { char * malloc(), * realloc(); Object key, * kp; extern int inc; if (t == mt) if (! table) if (table = (Object *) malloc(inc * sizeof(object))) mt = inc; else fputs("no room\n", stderr), exit(1); else if (! (table = (Object *) realloc(table, (mt += inc) * sizeof(object)))) fputs("no more room\n", stderr), exit(1); t ist die aktuelle Länge der Tabelle, mt die verfügbare Länge. Sind t und mt gleich, ist in der Tabelle kein Platz (mehr) vorhanden. Gibt s dann noch keine Tabelle, wird sie mit malloc() angelegt, sonst wird sie mit realloc() verlängert und dabei unter Umständen intern umkopiert. inc können wir global beeinflussen es ist selbstverständlich, daß man den Tabellenplatz nicht nur um einzelne Elemente vergrößert. key.word = word; kp = lsearch(& key, table, & t, sizeof key, cmpw); if (kp >word == word) kp >word = strsave(word), kp >freq = 1; else ++ kp >freq;

4 Anschließend wird ein Tabellenelement key als Suchobjekt initialisiert und damit lsearch() bemüht. Der Trick besteht darin, das Wort selbst erst dann dynamisch zu speichern, wenn es wirklich neu ist, wenn also lsearch() wirklich key in die Tabelle kopiert hat und das Tabellenelement auf den Puffer zeigt, der an count() selbst übergeben wurde. strsave() findet man zum Beispiel im Abschnitt 5.6 bei Kernighan und Ritchie oder als strdup() bei XENIX. An Stelle von lsearch() kann man auch unsere Funktion binary() 3 aufrufen. In diesem Fall ist natürlich der Aufruf von qsor t() in alpha() unnötig. Hier sind ein paar Meßergebnisse: 3 Diese Funktion aus dem ersten Teil des Artikels sucht binär und fügt bei Bedarf ein Element so ein, daß die Tabelle sortiert bleibt.

5 count() user system Aktivität inc alpha() freqency() Summe heap Leerlauf lsearch() binary() Leerlauf lsearch() binary() lsearch() binary() Im ersten Teil der Tabelle wurde der SpreadSheet-Artikel aus der vorigen Ausgabe der unix/mail bearbeitet, im zweiten Teil nur die sortierte Liste der Worte, im dritten Teil die gleiche Liste, aber mit sor t -rin umgekehrter Reihenfolge. Man beobachtet natürlich, daß binary() wesentlich effizienter ist als lsearch(). Man sieht aber auch, daß 50 eine schlechte Wahl für inc war: malloc() fordert von sbrk() Speicher in größeren Stücken an; kleinere Schritte in der Tabellenvergrößerung wirken sich folglich ungünstig aus. Eine umgekehrt sortierte Liste von Worten ist der ungünstigste Fall für binary() trotzdem funktioniert die Funktion hier immer noch so gut wie lsearch()! Daß bei gleicher Eingabe im dritten Teil mehr dynamischer Speicherplatz als im zweiten Teil verbraucht wird, liegt an der Verteilung der Wortlängen; vergrößert man inc wieder auf 100, geht der Speicherplatzverbrauch

6 auch wieder zurück. Suchbäume tsearch() und twalk() In Programmiervorlesungen stellt man das Häufigkeitsproblem normalerweise als Aufgabe zu struct und dynamisch aufgebauten Datenstrukturen, nämlich zu binären Bäumen: typedef struct node Node; /* Knoten im Baum */ struct node { char * word; int freq; /* die Information */ Node * left, * right; /* die Unterbaeume */ ; In einer früheren Sprechstunde habe ich den üblichen iterativen Algorithmus gezeigt, mit dem man Worte so in einen binären Baum einträgt, daß er bei einer postorder- Traverse 4 sortiert erscheint. Inzwischen gibt es diesen Algorithmus als Büchereifunktion: #include <search.h> /* definiert VISIT */ char * tsearch(), * tfind(), * tdelete(); void twalk(); #define Tsearch(key, rootp, compar) \ 4 Nach Don Knuth s The Art of Computer Programming (Addison-Wesley 1968) unterscheidet man preorder (Wurzel vor Unterbäumen bearbeiten), postorder (Wurzel zwischen linkem und rechtem Unterbaum) und endorder (Wurzel nach Unterbäumen). In der zweiten Auflage wurde postorder zur sinnvolleren inorder, und endorder dann zu postorder. Bei System V glaubt man noch an die erste Auflage.

7 ((Object **) tsearch((char *) (key), /* gesuchtes Object */ \ (char **) (rootp), /* > > Wurzel */ \ (int (*)()) (compar))) /* Vergleichsfunktion */ #define Tfind(key, rootp, compar) \ ((Object **) tfind((char *) (key), /* gesuchtes Object */ \ (char **) (rootp), /* > > Wurzel */ \ (int (*)()) (compar))) /* Vergleichsfunktion */ #define Tdelete(key, rootp, compar) \ ((Object **) tdelete((char *) (key), /* gesuchtes Object */ \ (char **) (rootp), /* > > Wurzel */ \ (int (*)()) (compar))) /* Vergleichsfunktion */ #define Twalk(root, action) \ (twalk((char *) (root), /* > Wurzel */ \ (void (*)()) (action))) /* Aktion */ tfind() sucht Information in Form eines Zeigers(!) key in einem Suchbaum, auf dessen Wurzel ein Zeiger zeigen muß, dessen Adresse (Zeiger auf Zeiger!) als rootp übergeben wird. Der Suchbaum ist postorder-sortiert im Sinne der Vergleichsfunktion compar. Die Vergleichsfunktion erhält, wie bei den bisher betrachteten Suchoperationen, wieder zwei Zeiger des Typs, der als erstes Argument an tfind() geliefert wird. Als Resultat liefert tfind() bei Mißerfolg natürlich einen Nullzeiger, bei Erfolg aber einen Zeiger auf den Punkt im Suchbaum, bei dem die Information als Zeiger gespeichert ist, die compar als gleich zur Argument- Information betrachtet. Ein Unterschied zwischen lfind() und tfind() ist also, daß lfind() ein Resultat vom Typ des ersten Arguments liefert, tfind() aber einen Zeiger auf ein Datum mit dem Typ des ersten Arguments. tsearch() funktioniert wie tfind(), trägt aber bei Bedarf den als erstes Argument übergebenen Informationszeiger in den Suchbaum ein. tsearch() liefert einen Nullzeiger entweder, wenn als rootp ein Nullzeiger übergeben wird (das ist ein

8 Fehler), oder wenn kein dynamischer Speicherplatz zum Ausbau des Baums mehr vorhanden ist. tsearch() liefert einen Zeiger auf seinen ersten Argumentwert, wenn genau der Argumentwert im Baum gefunden oder gerade eingetragen wurde. Wir können also count() wieder implementieren: static int nel; /* Anzahl verschiedener Worte */ static char * root; /* Zeiger auf den Baum; NULL, also leer */ count(word) register char * word; { char * malloc(); register Object ** opp; Object key; key.word = word; if (! (opp = Tsearch(& key, & root, cmpw))) fputs("no tree room\n", stderr), exit(1); if (*opp == & key) { if (! (*opp = (Object *) malloc(sizeof(object)))) fputs("no node room\n", stderr), exit(1); (*opp) >word = strsave(word); (*opp) >freq = 1; ++ nel; else ++ (*opp) >freq; Object, strsave() und die Vergleichsfunktion cmpw() werden vom lsearch()-beispiel aus dem ersten Teil des Artikels übernommen. Wieder wird das Suchobjekt key initialisiert und damit tsearch() aufgerufen. Beim ersten Mal sollte ein leerer Baum als zweites Argument übergeben werden: root hat, als globale Variable, einen Nullzeiger als Anfangswert, und dessen Adresse repräsentiert dann einen leeren Baum.

9 tdelete() funktioniert ähnlich wie tfind(), das heißt, Information wird im Suchbaum lokalisiert. Anschließend verändert tdelete() den Suchbaum allerdings so, daß diese Information nicht mehr im Suchbaum steht: tdelete() löscht ein Element aus dem Suchbaum. Eine äquivalente Funktion gibt es bei den anderen Funktionsfamilien nicht. tdelete() ist jedoch keine glückliche Lösung um effizient einen ganzen Suchbaum zu löschen. Als Resultat liefert tdelete() bei Erfolg entweder einen Zeiger auf die Information im Vorgänger des gelöschten Elements im Suchbaum, einen Zeiger auf die Information im gerade gelöschten(!) Element, wenn es die Wurzel des Suchbaums war, oder einen Nullzeiger, wenn nichts gelöscht werden konnte. Dieser Aspekt von tdelete() ist nicht optimal überlegt. Gegenüber einer von lsearch() unterhaltenen Liste hat ein von tsearch() konstruierter Baum den Vorteil, daß er meistens effizienter durchsucht werden kann, und daß die Information im Baum auch in sortierter Reihenfolge erreichbar ist. Gegenüber unserer Funktion binary() sucht tsearch() meistens weniger effizient, muß aber dafür bei neuen Einträgen nichts verschieben. Baumtraversen realisiert die Funktion twalk(): für jedes Blatt im Suchbaum ruft sie eine vom Benutzer zu programmierende Funktion einmal auf, für jeden anderen Knoten dreimal. Die verschiedenen Argumente sind ein bißchen kompliziert: twalk() erhält direkt den Zeiger auf die Wurzel des Suchbaums ( ein Sternchen weniger als tsearch() ) und dazu die Benutzerfunktion. Die Benutzerfunktion erhält als erstes Argument einen Zeiger auf den Zeigerwert, der im Suchbaum eingetragen ist ( ein Sternchen mehr als die Vergleichsfunktion ) und der gerade besucht wird, als zweites Argument (C-Kür, Sie erinnern sich?) einen enum-wert, nämlich leaf, preorder, postorder oder endorder, und als drittes Argument das aktuelle Baumniveau. alpha() ist eine typische Anwendung von twalk(): static void visit(opp, order) register Object ** opp; VISIT order;

10 { switch (order) case leaf: case postorder: puts((*opp) >word); alpha() { twalk(root, visit); VISIT ist der enum-typ und stammt aus der öffentlichen Definitionsdatei search.h. visit() ist unsere Benutzerfunktion wir geben Worte alphabetisch aus, wenn wir Blätter oder Knoten in postorder erreichen. Hängt von switch() nur eine Anweisung ab, kann man ihr die case-marken voranstellen und auf die geschweiften Klammern verzichten. Für frequency(), die Ausgabe nach Häufigkeit, muß man umsortieren. Wir verwenden twalk() dazu, dynamisch einen Vektor von Zeigern auf unsere Object- Strukturen zu konstruieren. Den Vektor können wir dann mit qsor t() nach Häufigkeit sortieren und ausgeben: static int cmpf(a, b) register Object ** a, ** b; /* Vergleich */ { register int c; return (c = (*a) >freq (*b) >freq)? c : cmpw(*a, *b); static Object ** ptr; /* naechstes Vektorelement */ static void enter(opp, order) Object ** opp; VISIT order; /* baut Vektor */ { switch (order) case leaf: case endorder: *ptr++ = *opp;

11 frequency() { register Object ** table; register int i; char * malloc(); if (nel) { if (! (table = (Object **) malloc(nel * sizeof(object *)))) fputs("no room for index\n", stderr), exit(1); ptr = table; twalk(root, enter); Qsort(table, nel, cmpf); for (i = 0; i < nel; ++ i) puts(table[i] >word); free(table); Bei der Vergleichsfunktion cmpf() ist Vorsicht geboten: wir sortieren nicht mehr einen Vektor von Object-Strukturen sondern einen Vektor von Zeigern darauf. Da der Komponentenverweis -> Vorrang vor der Verweisoperation * hat, muß man wie oben klammern. Da die Werte der.freq-komponenten positiv sind, kann man die Differenz als Resultat des Vergleichs heranziehen. Es lohnt sich leider, dieses Beispiel auch noch auszuprobieren:

12 count() user system Eingabe alpha() freqency() Summe heap Artikel sortiert core dump sortiert* Artikel sortiert sort -r Vergleicht man mit der Tabelle zu lsearch() und binary() stellt man fest, daß tsearch() im Normalfall erheblich weniger Rechenzeit verbraucht dafür ist der Speicherverbrauch höher, denn irgendwo muß der Suchbaum schließlich stehen. Weniger schön ist die Reaktion, wenn die Worte sortiert eintreffen: der binäre Baum artet in eine lineare Liste aus und die Verfolgung von Zeigern ist dann noch geringfügig langsamer als das Absuchen eines Vektors. Der Zeitverlust ist nicht das einzige Problem. Bei einem normalen binären Baum muß twalk() rekursiv traversieren ein entarteter Baum verursacht dann entweder einen hohen Platzverbrauch auf dem Stack oder, wie hier bei XENIX den Prozeßabbruch. Mit einem bösartigen Trick kann man das Problem teilweise vermeiden: sortiert* bezieht sich auf einen Versuch, bei dem zuerst durch Eingabe von 52 Worten ein möglichst balancierter Baum gebildet wurde, zu dem dann erst die sortierte Liste der Worte aus dem Artikel hinzugefügt wurde. Die 52 Worte waren die Klein- und Großbuchstaben des Alphabets; die Balance des Baums wurde durch Verwendung des in einer früheren Spalte beschriebenen unsort-filters approximiert, der aus einer sortierten Eingabe einen Suchbaum minimaler Höhe bildet und ihn dann in preorder ausgibt, wodurch er bei der Eingabe zu tsearch() wieder mit minimaler Höhe

13 aufgebaut wird. Daß es auch anders geht, demonstriert der zweite Teil der Tabelle. Er beruht auf meiner Implementierung der tsearch()-funktionen mit Hilfe von binary threaded trees, 5 bei denen die Nullzeiger in den Blättern des Suchbaums so umfunktioniert werden, daß man preorder- und postorder-traverse iterativ ablaufen lassen kann. Für entartete Bäume funktionieren diese Funktionen etwas schlechter als binary(), aber als iterative Algorithmen vermeiden sie den hohen Platzverbrauch auf dem Stack mit seinen unangenehmen Konsequenzen. Klotzen malloc() Warum benötigt die Lösung mit binary threaded trees weniger dynamischen Speicherplatz? Wie im Kapitel 8 bei Kernighan und Ritchie nachzulesen ist, muß malloc() extern zu jeder vergebenen Speicherfläche Information aufbewahren, mit deren Hilfe free() später noch die Größe der Speicherfläche feststellen kann. Unsere Object-Struktur ist nicht sehr groß. Fordert man viele derart kleine Flächen an, die man ja in unserem Beispiel ohnehin nicht wieder freigibt, fällt die unsichtbare Information für free() stark gegenüber der nutzbaren Information in jedem Object ins Gewicht. Es ist also besser, wenn man bei count() nicht so sehr kleckert: count(word) register char * word; { char * malloc(); extern int inc; register Object ** opp; 5 Die Quellen sind zu lang für diese Spalte. Sie stehen im Kapitel 18 der Buchausgabe der UNIX Sprechstunde Hanser 1987 und auf der Diskette zu diesem Buch.

14 static Object * table; static int t; /* Speicherstueck */ if (! t &&! (table = (Object *) malloc((t = inc) * sizeof(object)))) fputs("no room\n", stderr), exit(1); table[ t].word = word; if (! (opp = Tsearch(& table[t], & root, cmpw))) fputs("no tree room\n", stderr), exit(1); if (*opp == & table[t]) ++ nel, (*opp) >word = strsave((*opp) >word), (*opp) >freq = 1; else ++ t; ++ (*opp) >freq; So holt man sich von malloc() Platz für inc Worte und gibt ihn dann mit absteigenden Indizes an den Suchbaum ab. Gibt man den Speicherplatz nicht mehr frei, kann man ihn auch direkt mit dem Systemaufruf sbrk() beim Systemkern 6 anfordern. Der Aufruf ist identisch zu malloc(). Es liegt zwar nahe, diese Funktion im Stil des lsearch()-beispiels so auszubauen, daß der Vektor table[] bei Bedarf mit realloc() verlängert wird, denn dann kann man sich den zusätzlich dynamisch angelegten Vektor für frequency() sparen, aber diese Lösung geht schief: Ist hinter der an realloc() übergebenen Fläche kein Platz mehr vorhanden, kopiert realloc() stillschweigend in eine neue, größere Fläche um. Die Zeiger auf die alte Fläche, die dann per tsearch() in unserem Suchbaum gespeichert sind, zeigen anschließend ins Leere und später in eine Gegend, die malloc() vermutlich neu vergeben hat! Man kann sich dadurch behelfen, daß man an Stelle 6 sbrk() wird in der System V Interface Definition nicht mehr erwähnt. Für malloc() gibt es eine neue Implementierung, bei der man kleine Blöcke bevorzugt behandeln lassen kann. Meine Versuche bei XENIX endeten allerdings mit einer Endlosschleife.

15 von Zeigern im Suchbaum Indexwerte in den Vektor table[] speichern läßt, denn diese Indexwerte ändern sich natürlich nicht, wenn realloc() den Vektor umkopiert: static Object * table; static int t, mt; static char * root; count(word) register char * word; { char * malloc(), * realloc(); extern int inc; register int * ip; if (t == mt) if (! table) if (table = (Object *) malloc(inc * sizeof(object))) mt = inc; else fputs("no room\n", stderr), exit(1); else if (! (table = (Object *) realloc(table, (mt += inc) * sizeof(object)))) fputs("no more room\n", stderr), exit(1); table[t].word = word, table[t].freq = 0; if (! (ip = (int *) Tsearch(t, & root, cmpw))) fputs("no tree room\n", stderr), exit(1); if (*ip == t) table[t].word = strsave(table[t].word), ++ t; ++ table[*ip].freq; static visit(ip, order) register int * ip; register VISIT order; { switch (order) case leaf: case postorder: puts(table[*ip].word);

16 int-werte kann man an Stelle von Zeigern übergeben, aber dadurch ändert sich natürlich die Interpretation des Resultattyps von tsearch(). Nach wie läßt alpha() durch twalk() den Baum traversieren, aber auch bei visit() taucht jetzt ein anderer Typ aus dem Suchbaum auf wie immer der gleiche, den tsearch() als Resultat liefert, und damit ein Sternchen mehr als das erste Argument von tsearch(). Die Funktion frequency() befaßt sich mit dem Vektor table[] und wurde deshalb schon im lsearch()-beispiel gezeigt. Raten hsearch() Wenn man zum Beispiel nur die 26 Buchstaben des Alphabets unterscheiden muß, wird man kaum einen Suchbaum bemühen. Für kleine Wertemengen stellt man einen Vektor zur Verfügung und berechnet die Indexwerte mit einer Funktion, die einen Wert einem Vektorelement zuordnet. Auf dieser Idee beruhen die sogenannten Hash-Verfahren, bei denen ein Vektor fixer Länge als Tabelle verwendet wird. Eine Hash-Funktion berechnet aus dem Suchschlüssel einen Index in die Tabelle, und so wird zunächst überhaupt keine Vergleichsoperation benötigt. Da jedoch viele mögliche Suchschlüssel (bei uns alle vorstellbaren Worte) wenigen Tabellenplätzen gegenüberstehen, kann die Hash- Funktion nicht eindeutig sein, und man muß den Suchschlüssel wenigstens mit einem Tabelleneintrag vergleichen. Streut die Hash-Funktion sehr gut, bleibt s bei dem einen Vergleich und das Verfahren ist jeder anderen Methode überlegen. Bildet die Hash-Funktion mehrere tatsächlich verwendete Suchschlüssel auf den gleichen Tabelleneintrag ab, muß man einen Algorithmus zur Auflösung der Kollisionen verwenden. Dieser Algorithmus hat oft zur Folge, daß aus einer Hash-Tabelle keine Einträge gelöscht werden können die Tabelle muß also größer angelegt werden,

17 als die maximal erwartete Anzahl von Einträgen, denn die Auflösung von Kollisionen wird natürlich schwieriger, wenn die Tabelle fast voll ist. hsearch() implementiert ein Hash-Verfahren. Im Gegensatz zu allen anderen Suchfunktionen kann hsearch() jedoch nur eine einzige, unsichtbare Tabelle manipulieren. Sie wird mit hcreate() erzeugt dabei legt man ihre Größe fest und sie kann mit hdestroy() insgesamt zerstört werden. hsearch() folgt völlig anderen Konventionen als die anderen Suchfunktionen: das erste Argument ist eine Struktur(!) vom Typ ENTRY, der in der öffentlichen Definitionsdatei search.h vereinbart wird; das zweite Argument ist der enum-wert FIND, wenn nur gesucht werden soll, oder ENTER, wenn bei Bedarf auch eingetragen werden soll. Auch diese Werte sind in search.h definiert. ENTRY hat eine erste Komponente.key, die auf den String zeigt, der als Suchschlüssel verwendet werden soll. Die zweite Komponente.data ist ein (beliebiger) Zeiger. hsearch() liefert als Resultat einen Zeiger auf einen ENTRY in der Hash-Tabelle (also auf eine Kopie des ersten Arguments) und im Fehlerfall einen Nullzeiger, wenn es bei FIND keinen entsprechenden Eintrag gibt, oder wenn bei ENTER die Tabelle voll ist. Da die Hash-Tabelle von hsearch() verborgen wird und ohnehin nicht sortiert ist, müssen wir diesmal alle Worte selbst noch auffädeln: #include <search.h> typedef struct { /* unsere Information fuer.data */ ENTRY * next; /* lineare Liste der Worte */ int freq; /* Haeufigkeit */ Data; /* Zugriffsmakros */ #define Ekey(ep) ((ep) > key) /* Wort */ #define Edata(ep) ((Data *) (ep) > data) /* Information */ #define Efreq(ep) (Edata(ep) > freq) /* Haeufigkeit */

18 #define Enext(ep) (Edata(ep) > next) /* lineare Liste */ static int nel; /* Anzahl Worte */ static ENTRY * list; /* lineare Liste */ Mit Zugriffsmakros kann man allzu schlimme Zeigerausdrücke vermeiden. Sie werden für jede interessante Komponente einmal formuliert, hängen zweckmäßigerweise von einem Zeiger auf ein Element der Hash-Tabelle ab, und sind nebeneffektfrei und als L-Werte formuliert, damit man sie in jedem Kontext verwenden kann. count() legt beim ersten Aufruf eine Hash-Tabelle mit inc Einträgen an: count(word) register char * word; { char * malloc(); ENTRY item, * ep, * hsearch(); static Data data; extern int inc; if (! list &&! hcreate(inc)) fputs("no hash room\n", stderr), exit(1); Ekey(& item) = word, Edata(& item) = & data; Anschließend wird das Suchobjekt gebildet. data ist static definiert und hat damit eine.freq-komponente mit Wert 0. Jetzt können wir hsearch() bemühen: if (! (ep = hsearch(item, ENTER))) fputs("no more hash room\n", stderr), exit(1); if (! Efreq(ep)) { if (! (Edata(ep) = (Data *) malloc(sizeof(data)))) fputs("no data room\n", stderr), exit(1); Ekey(ep) = strsave(word), Efreq(ep) = 1; Enext(ep) = list, list = ep; ++ nel;

19 else ++ Efreq(ep); Ist dann die.freq-komponente immer noch 0, wurde unser Suchobjekt gerade kopiert, das heißt, in der Hash-Tabelle stehen jetzt Zeiger auf unser word (auf unserem Stack!) und auf unsere Struktur data. Wir speichern deshalb das Wort dynamisch, legen die Information data dynamisch an, verketten mit unserer Liste und initialisieren den Häufigkeitszähler. Auch hier sollte man malloc() entlasten und größere Blöcke auf einmal anfordern. alpha(), frequency() und die zum Sortieren nötigen Vergleichsfunktionen sind Variationen zu einem bekannten Thema wenn man unsere Zugriffsmakros verwendet: static int cmpw(a, b) register ENTRY ** a, ** b; { return strcmp(ekey(*a), Ekey(*b)); alpha() { visit(cmpw); static int cmpf(a, b) register ENTRY ** a, ** b; { register int c; return (c = Efreq(*a) Efreq(*b))? c : cmpw(a, b); frequency() { visit(cmpf);

20 visit() leistet in beiden Fällen die gleiche Arbeit: für die lineare Liste muß ein Vektor mit Zeigern angelegt werden, der dann per qsor t() sortiert und ausgegeben werden kann. Man könnte auch wieder in count() mit realloc() einen Vektor dynamisch vergrößern und in der Hash-Tabelle als.data nur Indexwerte speichern, aber die vorliegende Lösung ist vermutlich klarer: static visit(cmp) int (* cmp)(); { register ENTRY ** table, ** tp, * ep; register int i; char * malloc(); if (nel) { if (! (table = (ENTRY **) malloc(nel * sizeof(entry *)))) fputs("no room for index\n", stderr), exit(1); for (ep = list, tp = table; ep; ep = Enext(ep)) *tp++ = ep; Qsort(table, nel, cmp); for (i = 0; i < nel; ++ i) puts(ekey(table[i])); free(table); Wie gut das Hash-Verfahren funktioniert, zeigt folgende Tabelle:

21 count() user system inc Eingabe alpha() freqency() Summe heap 966 Artikel sortiert Artikel sortiert Artikel sortiert Man sieht, daß das Hash-Verfahren selbst besser funktioniert als der Einsatz von Suchbäumen. Muß man sortiert ausgeben, benötigen bei unserem Beispiel beide Methoden insgesamt gleich viel Zeit und Speicherplatz. Das Hash-Verfahren ist vielleicht etwas komplizierter zu codieren, hat dafür aber den Vorteil, daß es auch bei sortierter Eingabe nicht zusammenbricht. Sehr wesentlich ist, daß das Verfahren auch dann nahezu gleich schnell abläuft, wenn die Tabelle mit 966 Worten 7 vollständig gefüllt wird. 7 Fordert man mit hcreate() genau 966 Tabelleneinträge an, kann man 1023 Worte speichern hcreate() macht die Tabelle möglicherweise etwas größer, damit die Hash-Methode korrekt funktioniert. Füllt man die Tabelle wirklich ganz, ändert sich das Zeitverhalten kaum.

22 Zusammenfassung Ist jetzt die richtige Wahl so schwer, daß man die nächste Suchoperation doch wieder selber programmiert? Ich glaube nicht. Beim Schreiben dieses Artikels habe ich mir vor allem die Aufrufkonventionen aller Funktionen klar gemacht, und in Zukunft würde ich folgendermaßen vorgehen: hsearch() ist allen anderen Methoden überlegen, falls man nicht (viele) Elemente wieder löschen muß, oder den Platzbedarf überhaupt nicht voraussehen kann, oder falls man nicht (oft) im Währenden sortiert ausgeben muß. lsearch() hat meines Erachtens keine mildernden Umstände. Für binary() spricht dagegen eine wesentlich verbesserte Effizienz sowie die Möglichkeit, daß man jederzeit garantiert neue und/oder sortierte Information zur Tabelle insgesamt hinzufügen und die Tabelle dann mit qsor t() für binary() wieder verwendbar machen kann. binary() würde ich verwenden, wenn ich den Platzbedarf nicht kenne, viel suchen und wenig neu eintragen muß, und vor allem, wenn häufig aber nicht vorhersehbar mit sortierter Information zu rechnen ist. tsearch() funktioniert so gut wie hsearch(), wenn sortiert ausgegeben werden muß, und wenn die angebotene Information nicht entartet. Bei hsearch() muß ein String als Suchschlüssel verwendet werden, bei tsearch() liefert man die Vergleichsfunktion selbst. Bäume können beliebig wachsen, Hash-Tabellen nicht, und die Probleme bei sortierter Information habe ich in meiner Implementierung entschärft.