in reply to Coloring IRC logs nicely

Precalculate 64 colors based on your color distance formula. As nicks show up, draw from the pool. As nicks /part, recycle that color. If 64 colors result in some colors being indistinguishable, use other attributes such as italics or underline. For this, you'll need a viewer that can handle these other attributes. If 64 isn't a big enough number, stay out of #cybersex in the future (just kidding).

This sounds like a job for object orientation too, where individuals are object instances, and the underlying class handles the details of keeping track of allocating display attributes to the individuals, as well as the details of outputting the proper sequences to display individual's attributes.


Dave

Replies are listed 'Best First'.
Re^2: Coloring IRC logs nicely
by iblech (Friar) on Aug 19, 2004 at 17:12 UTC
    • My first algorithm: Uses the minimum number of colors necessary (= maximum contrast), but slow.
    • Your and Jaaps idea: Always uses a fixed number of colors (=contrast stays the same all the time), but fast.

    I hoped for a mix between those two solutions, but I think that's not possible: To build the interference graph, one has to know all future nicks. Your solution trades "perfection" for speed.

    Maybe I can use some heuristics:

    I read the first 100 (or so) lines. Based on the number of different nicks seen, I select the size of the pool. If many people (more than colors available) /JOIN after I set the size of the pool, that's "bad luck".

    Thanks Jaad and davido, I think I'll use your solutions.

      I agree that the precomputed method is faster, but the reason I proposed it wasn't because of its speed advantage. What I heard in your original post is that you really have no good way of knowing ahead of time how many nicks you'll be following, and that the color distance formula really needed to know that. So the color distance formula really only works if you decide ahead of time how many nicks you'll be following. Of course you don't have to use all of the ones you precompute, but you just hold them like cards in a deck, and hand them out as needed.


      Dave

      There's no reason why the two methods are mutually exclusive. You can retain contrast for small numbers of nicks by working out the fixed colors and then sorting them in an array so that the 3 primary colours appear first, then the 3 secondary colors, then the 6 tertiary colors, etc.
      @colors = qw(ff0000 00ff00 0000ff ffff00 ff00ff 00ffff);
      This will ensure that the first 3 nicks get a good contrast between the colors, then the next 3 get the second-best level of contrast ad infinitum.
        This will ensure that the first 3 nicks get a good contrast between the colors, then the next 3 get the second-best level of contrast ad infinitum.

        Yes, that's no problem. But: The first nicks are not necessarily the most active nicks, example:

        • A..F join (colors: most contrast)
        • A..F idle
        • G,H,I join (colors: less contrast)
        • G,H,I flame or are otherwise active

        To work around that, the nicks would have to be sorted for activeness -- and to do that, we'd need knowledge of all further nicks. And then, we could just use my first algorithm.