Golf a number
Create a program or function, which when given an input integer, outputs a mathematical expression evaluating to the same value. Expressions which require fewer bytes to represent than the integer itself will achieve better scores!
It is often useful when golfing to compress constant integer expressions by expressing them in the form of an equivalent mathematical expression.
387420489 for example is much more efficiently expressed as
The challenge is, for each integer in the range
1 to 1E6, to golf the number into as short an expression as you can (although any expression which evaluates correctly is acceptable output, see Rules below). The shorter the expression, the better your score; but short programs will also score well so the two need to be balanced!
Input integer as argument or from STDIN
Output as string or equivalent to STDOUT or as function output. Your string can only contain ascii characters [
9], as well as those operators defined below, repetitions allowed.
You may use the following mathematical operators any number of times in your string:
\ integer(floor) division - see Test Evaluator
NB: division, integer division and multiplication are all evaluated with equal priority, so
3/2\2 = 0 whereas
3\2/2 = 0.5
You may output the input value (if it can't be golfed for example), you do not have to output the perfectly golfed string:
However the output must evaluate exactly to the input (assuming perfect precision of floats)
Answers are scored on their compression ratio (how much they golf the input down on average), as well as program size
Program Size: byte count of program (as with normal code golf)
golfed Length (white-space ignored) / input Length
Individual Score =
(Compression Ratio * 100 - 70)/6 + Log(Program Size, base 10)
Final Score =
Mean score for first 10^6 integers
Lowest final score for each language wins!
The main sticking point is scoring how best can you combine 2 metrics into a single score?
The logic so far is that compression ratios will lie in the range 100 - 70 % where 100 is returning the input. Program lengths should be between 2 extremes; returning the input (1 byte) and looking up the input in a hardcoded list (~19,000,000 bytes). This gives the following distribution:
Actual program length I guestimate will be anywhere in the range 1 to 10000 bytes, hence the
log to make the range more manageable. Quick reference; I could probably implement all power golfing (expressing n as a^b) in ~100-200 bytes in VBA. So 10% of that for golfing languages, and who knows what builtins Mathematica has ;).
But implementing more effective algorithms may require a more verbose language, so I think 1 - 10000 seems like a good range to handle in scoring
Open to alternative scoring though, and any required clarifications. Also suggestions what is a good range to test over?
1 to 1E6; The first 1000 integers I don't think are golfable, after that only a few are. So perhaps a greater range of test cases, or ones starting at a larger initial value? What's the biggest range I can feasibly test within say, 10 mins running time max? What's typical algorithm execution times can be expected per digit? I don't want golfers to have to spend too long generating their average score...
Test String Evaluation