in reply to Re: What makes an array sorted and a hash unsorted?
in thread What makes an array sorted and a hash unsorted?

Hashes, on the other hand, are intrinsically not ordered internally. In fact, this feature is what allows for (relatively) inexpensive insertion and deletion. (Two items with keys very close to each other are likely to end up in different areas of the hash table.)
That's not correct. Hash keys are ordered, otherwise you wouldn't be able to quickly search for them (and hence, no quick deletion either). However, the order internally isn't the same order people want (this thread seems to consider "ordered hashes" as "keys are sorted" - it's not uncommon for people to mean "keys returned in insertion order" when they talk about "ordered hashes"). I've always understood that keys (and its friends) return the keys in the way they are laid out internally - so certainly "ordered", but only after applying a hash function.

Replies are listed 'Best First'.
Re^3: What makes an array sorted and a hash unsorted?
by gwadej (Chaplain) on Jun 02, 2009 at 03:40 UTC

    You are correct. I was sloppy with the term keys.

    It would be more accurate to say that the data is not ordered with respect to the original keys. However, it is ordered with respect to the result of the hash function applied to the keys.

    Given that a good hash function should distribute the data fairly evenly through the table (and that the hash function is often not known by the user), this is effectively the same as saying that the data is not ordered with respect to the original keys.

    G. Wade
[reply]
Re^3: What makes an array sorted and a hash unsorted?
by herveus (Prior) on Jun 02, 2009 at 12:32 UTC
    Howdy!

    Hash keys have no predefined ordering. Any given call to keys() will present the keys as a list which will, at that instant, have an order, but that particular ordering is neither persistent nor stable nor predictable in the face of insertions and deletions. Rapid searching for hash keys has nothing to do with ordering, but rather with the nature of hash functions. Ideally, any given key value hashes to a unique value in the hash that can be found (or the existence of tested for) in constant time. Searching an ordered list is going to be O(log n) or worse.

    yours,
    Michael
[reply]
      Searching an ordered list is going to be O(log n) or worse.
      If that were true, finding an item in an array would take logarithmic time (this thread has already established arrays are sorted). It doesn't of course, given the key, it takes constant time to find something in an array.

      Just because binary search on a list of sorted values is logarithmic doesn't mean any search is logarithmic.

[reply]
        Howdy!

        You appear to be conflating being ordered with being sorted and searching with simple access.

        Arrays are ordered. The elements have a defined order. Orderedness and sortedness are not the same thing. One speaks to the intrinsic sequencing of the elements of a collection (orderedness) while the other speaks to an externally imposed sequencing of the elements of a collection (sortedness).

        Searching for an element is different from accessing an element. In the first case, you don't know which element is the target, so you have to find it. Accessing a specific element means you have the index of the item already. For a hash, the index is a string; for an array, the index is an integer.

        You cannot speak generally of the intrinsic sequence of the elements of a hash. It is not a fixed quantity. Adding or removing elements can change the sequence in ways that are not readily predictable. Iterating over the elements first involves collecting the set of keys. That act turns them into a list which has an intrinsic order, but it's no longer a hash or a set. The set of keys has become an ordered n-tuple (where n is the number of keys), but it's no longer a set.

        yours,
        Michael
[reply]

In Section Meditations