in reply to Re: Coloring IRC logs nicely
in thread Coloring IRC logs nicely

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.

Replies are listed 'Best First'.
Re^3: Coloring IRC logs nicely
by davido (Cardinal) on Aug 19, 2004 at 17:59 UTC

    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

Re^3: Coloring IRC logs nicely
by icerunner (Beadle) on Aug 20, 2004 at 08:33 UTC
    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.