PSPP-BUG: Re: [bug #12931] ONEWAY transposes output rows/columns

[Ben Pfaff]

John Darrington <address@hidden> writes:

> You're right.  I added a quick hsh_sort in the relevant places and it
> seems to fix the problem, but I have some concerns about this:
>
> From hash.c:
> /* Sorts hash table H based on hash comparison function.
>    ....  After calling this function, only hsh_destroy()
>    and hsh_count() may be applied to H. */
>
> This implies that it's not safe to iterate a hash after sorting it.  
> Is it safe to do so?  And after sorting, will it iterate in the sorted
> order?  

Hmm.  I hadn't considered this question.  The purpose of
hsh_sort() is to transform a hash table into a sorted array, so
that afterward you just iterate through the sorted array that it
returns.  The sorted array is no longer a hash table, so you
can't use, say, hsh_probe() or hsh_find() or hsh_delete() on it.
It should work just fine for iteration with hsh_first/next(), but
why not just step through the array it returns?

In other words, the usage is something like this:

        table = hsh_create (...);
        ...Insert lots of stuff into hash table...
        for (array = hsh_sort (...); *array != NULL; array++) {
            ...Do something with *array, but don't use hash functions...
        }
        hsh_destroy (table);

If you need to both traverse the hash table in sorted order and
use hash table functions on it, you could use hsh_sort_copy(),
which returns a sorted *copy* of the hash table contents.  It's
slightly less efficient, of course, because it has to allocate
memory.

Hmm.  Perhaps I should enforce the hsh_sort() constraints with
some assertions.

-- 
"I don't want to learn the constitution and the declaration of
 independence (marvelous poetry though it be) by heart, and worship the
 flag and believe that there is a god and the dollar is its prophet."
--Maarten Wiltink in the Monastery