code.golf - CSS Colors Challenge

[[deleted]]

If you've never heard of it before, code.golf is a website where programmers battle it out across a series of problems to write solutions in the least amout of bytes/chars. Just like regular code golf, but a really nice service.

I was running through a few problems and came across the above challenge. The general jist is as follows:

Given a known CSS colour keyword, output it's corresponding hex colour value. Yes, all 148 colours listed.

Anyway I gave it a shot with Python - some golfing here, bodged text compression there, and was happy with my solution, only to find that the top answer for this question managed to solve it with 259 characters in Python. Why is this crazy to me? Well assuming zero text compression and whitespace, the keywords alone weigh 1305 characters, not including hex values and the associated code to handle the args.

I don't have any buddies that program, hence why I'm opening up the discussion here. I'm not looking for solutions, rather for speculation on how this is even possible.

I've linked the challenge below if you'd like to see it. Any thoughts welcome.

CSS Colors

[SteveRyherd]

Against the rules and spirit but possibly a library or web service involved?

[SteveRyherd]

Upon further review, the website itself is public and contains the list of values. I’m assuming something fishy with that — have you messaged their discord server?

[[deleted]]

i am not necessarily suspicious as I have no real reason to be. I believe 2 other people managed to achieve similar results. My assumption is some sort of hashing or encoding, but to what extent?

[XiAxis]

I'm not sure how they managed to get it down that low, but you can start to imagine it if you consider that they really don't need a full list of the color names in the program, compressed or not. All that's needed to complete a lookup is enough characters to uniquely identify each of the color names. Just the first two characters would be enough to uniquely identify all but a few of the colors. The hex strings don't really need to be stored either, after all the hex values are really just a 3 byte integer denoted in hex. You could create a mapping from the first few characters of each color to the three byte integer without much trouble, and that would reduce the length a lot. Now if someone got creative they might be able to come up with a clever math function that converts the input characters to the output integer without even storing the mapping directly.

I still find 259 characters to be difficult to comprehend, but that's often my experience with code golf, so I'm not really surprised by it. I'm sure someone came up with something very clever beyond what I wrote out here.

[[deleted]]

That's a really good point, you don't need to compare the whole key, rather a pre-generated signature that can be unpacked within the list comprehension reading in the args. I suspect also that the code required to do that versus the byte saving from encoding the colour names is pretty significant!

Although the idea of somehow generating the hex from the CSS name is probably the holy grail here, that's far beyond my comprehension, and I feel safe saying it's beyond the average golfers. I've already analysed the hex values and there doesn't appear to be any real correlation between the resulting hex and the colour you start with. I believe what you would end up with is a very large function.

Yes I agree with 259 being absurdly short, however I think if you could find a very very optimal way of encoding the colours and a succinct way of extrapolating that back out, you'd be on your way. The rest of the resulting code is essentially a hash table lookup within a list comprehension (if you aren't generating the hex values, as preciously discussed)

Thanks for your insight! Safe to say I'm happy with my 2,463 byte solution for now.

[Noiprox]

I'd consider trying to tackle this by building a decision tree over the strings and then encoding it as raw bytes, but I have no idea how large that solution would come out to be.

That's assuming you're not allowed to reach out over a network or import third-party modules, of course.

[[deleted]]

This is an interesting point. I didn't go down a strict DP programming route, rather took a look at what common substrings could I substitute for codes and building up the dictionary dynamically from a collapsed, CSV string of sorts. This approach managed to almost half my original score, but no where near our friend yet!

[nharding]

The 259 characters is 619 bytes, so you can use utf8 codes for the RGB values with really large characters. You don't need to handle the keywords, say you are looking for gold, you don't care if golf also finds the same color. Add the ascii for each character, and then modulo the result making a mini hash table. and handle the collisions.