American flag sort

(xlinux.nist.gov)

257 points | by zerojames 24 days ago

17 comments

  • Someone 24 days ago
    The paper (https://static.usenix.org/publications/compsystems/1993/win_... linked to from the page) is well-written and worth reading, iterating over multiple C programs that build up to this sort algorithm and giving a good rationale for each iteration.
  • re 24 days ago
    Looks like there's a Rust implementation: https://crates.io/crates/afsort

    > When sorting English words, this implementation seems to be about 40% faster than sort_unstable from the Rust standard library.

    That's better than I would have expected. It would be interesting to see how it does on other types of string sort problems.

    • antonhag 24 days ago
      Hi! Crate author here, happy to see my old project getting mentioned. Let me know if you have any questions!
      • ewalk153 24 days ago
        Do you actively use this function in any projects? What was your inspiration to write the crate?
        • antonhag 24 days ago
          I don't actively use it, unfortunately. The main inspiration was to faster sort inputs into the https://github.com/BurntSushi/fst crate, which I in turn used to try to build a search library.
  • Kon-Peki 24 days ago
    Sorts like these work really well on GPUs. You would start with a single thread for the first pass and then keep spawning one-thread-per-bucket for every additional pass until done. It isn't particularly taxing on the GPU; your advantage comes from being able to run potentially thousands of threads simultaneously without having to worry about coordinating read/write memory access.
  • karmakaze 24 days ago
    At first I didn't think I'd be interested.

    > Using some efficiency techniques, it is twice as fast as quicksort for large sets of strings.

  • muti 24 days ago
  • jdeisenberg 24 days ago
    Wondering how this sort would perform with Unicode input (given 256 buckets); specifically what the results would look like.
    • dhosek 24 days ago
      Ignoring the fact that if you have Unicode encoded strings, you probably want some sort of lexical sort rather than a sort on the raw Unicode character codes which is semantically meaningless, there is no reason to assume that Unicode data would be any different to sort than any other data.
    • bawolff 24 days ago
      Presumably it would be fine, since unicode input is still a string of bytes at the end of the day.
      • moonchild 24 days ago
        Unicode collation is very complex. If you wanted to sort according to that, then you would need to devise an isomorphism between unicode strings and bitstrings such that lexicographic ordering in the bitstring domain agrees with unicode collation in the unicode domain. I'm not saying it's impossible, but it's not at all obvious how to do it. On the other hand, if all you want is some total order for acceleration structures, then you can indeed just use an arbitrary encoding like utf8 and do the obvious thing.
        • IncreasePosts 24 days ago
          Isn't that exactly what the Unicode collation algorithm is?

          https://unicode.org/reports/tr10

          tl;dr from its wikipedia page:

          > The Unicode collation algorithm (UCA) is an algorithm defined in Unicode Technical Report #10, which is a customizable method to produce binary keys from strings representing text in any writing system and language that can be represented with Unicode. These keys can then be efficiently compared byte by byte in order to collate or sort them according to the rules of the language, with options for ignoring case, accents, etc

        • bawolff 24 days ago
          You can just use the icu library to do that. Its a very common thing to do when working with unicode collations.
        • dsamarin 24 days ago
          The obvious solution to this is to pre-compile a list of all possible Unicode strings up to the required length, sort them, and create a lookup table using their indices. I wonder for what kind of project this would be useful.
          • thfuran 24 days ago
            If that works for you for anything but very small strings, I want to buy your computer.
          • remram 24 days ago
            Even for 3-codepoint strings it already wouldn't fit in any computer that exists. And that is not sufficient to encode all 1-glyph strings.
      • nanidin 24 days ago
        It says it sorts one byte at a time. I think this would break for anything not utf-8.
        • ts4z 24 days ago
          Seems like it should work for arbitrary byte strings (any charset, any encoding)but obviously the performance characteristics will differ because of non-uniform distribution. But that happens even in ASCII.
          • nanidin 22 days ago
            Yes, you’ll get something sorted based on the bytes in the string but it won’t be lexicographically correct - for example, à will be sorted after b.
        • brirec 24 days ago
          This would even break UTF-8, since multi-byte characters are a thing!
          • dumbo-octopus 24 days ago
            How would that break anything? The strings aren't being split.
          • ursusmaritimus 24 days ago
            Lexicographic encoding of UTF-8 byte sequences matches lexicographic order of the sequence of Unicode code-points. So you can sort UTF-8 strings as byte strings. Not that sorting by code-points has much meaning, but you can use the Unicode collation algorithm first.
            • mzs 23 days ago
              % printf "%s\n" A B | sort

              A

              B

              % printf "%s" A B | xxd -b -c4

              00000000: 11110000 10011101 10010000 10110100 ....

              00000004: 11110000 10011101 10010000 10110101 ....

              % printf "%s" A B | xxd -c1 -ps | sort | xxd -r -ps | xxd -b -c4

              00000000: 10010000 10010000 10011101 10011101 ....

              00000004: 10110100 10110101 11110000 11110000 ....

              % printf "%s" A B | xxd -c1 -ps | sort | xxd -r -ps

              ????????

            • remram 24 days ago
              TIL, thanks. That makes sense given how the length prefixes look like but I never thought about it. I wonder if this was by chance or if the UTF-8 creator thought about it.
          • nanidin 22 days ago
            Indeed, and is à less than b? Not in Unicode!
          • EmilyHughes 24 days ago
            UTF-8 is downward compatible to ASCII, so anything that is just a standard character (like every character in this comment) is just a byte.
    • seanhunter 24 days ago
      I think unicode is intrinsically antithetical to freedom. This would do great with ASCII.
  • jon_richards 23 days ago
    The stars in the American flag aren't used. This is clearly Pride flag sort.
    • oniony 23 days ago
      And Mauritius's flag has more stripes.
  • defrost 24 days ago
    There's a Peter M. McIlroy as well!?!

    All this time and I thought it was just Doug, I'm guessing Peter might be the son of the father of pipe?

    • icsa 24 days ago
      Yes. He is a software engineer in Seattle.
  • NikkiA 24 days ago
    This strikes me that it should parallelize pretty well if you deputise the individual stripes to multiple threads.
  • franze 23 days ago
    today i coded franzSort, faster than mergeSort, slower than quickSort

    function franzSort(a) { function m(l, r) { let s = []; while (l.length && r.length) { if (l[0] <= r[0]) { s.push(l.shift()); } else { s.push(r.shift()); } } return s.concat(l).concat(r); }

        if (a.length <= 1) {
            return a;
        }
        let h = Math.floor(a.length / 2);
        return m(franzSort(a.slice(0, h)), franzSort(a.slice(h)));
    }

    // Example usage let arr = [5, 3, 8, 6, 2, 7, 1, 4]; let sortedArr = franzSort(arr); console.log(sortedArr);

  • Zelizz 24 days ago
    Pretty much just a variation of counting sort with a worse name? https://en.wikipedia.org/wiki/Counting_sort
    • dumbo-octopus 24 days ago
      No. The very article you link details the difference, and that Counting Sort is often a subroutine in Radix Sort, and that Counting Sort is extremely poorly suited to strings, which is the entire purpose of this sort. And this name is better. So... "no" in basically every way possible.
      • Zelizz 24 days ago
        Characters in a string can be thought of as digits in a base-256 number. Call counting sort recursively on each bucket, looking at the next character in the string. Can you not see the similarity?
        • chowells 24 days ago
          There is no one who fails to see the similarity, because they're both kinds of radix sorts. For instance, a counting sort is a degenerate form of radix sort that only does one pass.

          But where the classic radix sort is bottom-up, the American flag sort is top-down. That really matters for data where the the most significant portions of the data is likely to be all you need to consider for the sorting. While a top-down sort will have similar performance to bottom-up in the worst case, in the best case it can skip a lot of passes, especially if the inputs are much longer than the longest common prefix.

        • dumbo-octopus 24 days ago
          They're related, but in a very specific way that does not meet the bar for "variation" in my opinion. As you described, counting sort is a very simple procedure that works well only on a very specific input domain. If another algorithm has "more logic" than counting sort itself in order to transform a very different input domain into a format that is suited for making many repeated calls to (a procedure that may be implemented as) counting sort, in a specific pattern, and appropriately coalescing the results of those calls, I think it is appropriate to let it have its own name. Would you prefer to refer to every possible utilization of counting as "that version of counting sort where...."?
    • sltkr 24 days ago
      American flag sort is essentially an in-place version of counting sort.

      That's talking about the single-pass American flag sort. If you use American flag sort to sort strings, you do multiple passes: on the first pass, you sort all strings by their first character, then for each starting character, you sort the strings with that starting character (which are now in a contiguous subarray) by their second character, and so on.

      @chowells calls it a “top-down radix sort” below, which is a great description. It also explains the strengths and weaknesses of the two algorithms: radix sort works great for small strings of fixed length (e.g. IPv4 addresses, which can be thought of as 4-byte sequences) while American flag sort works great for variable-length strings like actual textual strings, especially if they don't share common prefixes (e.g. dictionary words, usernames, etc.)

      @hinkley pointed out that the recursive version is just a bucket sort, but in-place. Which is also true!

      tl;dr:

      Single-pass American flag sort = in-place counting sort

      Recursive American flag sort = in-place bucket sort

    • carabiner 24 days ago
      A superior name.
  • Traubenfuchs 24 days ago
    > it is twice as fast as quicksort for large sets of string

    Define large.

  • Oarch 24 days ago
    The comments made me realise there's no national flag with lots of vertical stripes. Seems like a hole in the market.

    Someone alert CGP Grey!

  • tomphoolery 24 days ago
    Freedom Sort.
    • tom_ 24 days ago
      If you disagree, see the first amendment! If you still disagree, see the second amendment!
      • mondobe 24 days ago
        And if you STILL disagree, see the third amendment! If you're a soldier, in my house, I guess.
    • tomschlick 24 days ago
      Cue the Team America theme song
      • mcfedr 24 days ago
        That is basically what I hear in my head everytime I see that flag
    • tantalor 24 days ago
      For democracy!
  • owlninja 24 days ago
    The 'more information' site linked on the page seems like something some HN folk love.

    https://www.workmall.com/flags/united_states_flag.html