# TLDR Just the Puzzle

Given a number n and a weight w the function f will result in a weighted number r as follows.

f(n, w) = r

n can be a number from 0 to 200
w can be a number from -100 to 100 (including 0)

Some results using 100 as n:
f(100,-100) = 60
f(100,-99) = 60
f(100,-98) = 60
f(100,-97) = 60
f(100,-95) = 60
f(100,-94) = 61
f(100, -93) = 61
f(100, -91) = 61
f(100,-90) = 62
f(100,-88) = 63
f(100, -85) = 63
f(100,-84) = 64
f(100, -81) = 64
f(100,-80) = 65
f(100, -77) = 65
f(100,-76) = 66
f(100, -73) = 66
f(100,-72) = 67
f(100, -71) = 67
f(100,-70) = 68
f(100, -67) = 68
f(100,-66) = 69
f(100, -65) = 69
f(100,-64) = 70
f(100, -61) = 70
f(100,-60) = 71
f(100,-58) = 72
f(100,-54) = 73
f(100,-52) = 74
f(100,-50) = 75
f(100, 0) = 100
f(100, 50) = 150
f(100, 75) = 197
f(100, 90) = 250
f(100, 95) = 267
f(100, 98) = 288
f(100, 100) = 300

Some results using 200 as n:
f(200, -100) = 120
f(200, -88) = 126
f(200, 50) = 300
f(200, 100) = 600

Some results using 77 as n:
f(77, -100) = 46
f(77, -88) = 48
f(77, 50) = 115
f(77, 100) = 231

Some results using 1 as n:
f(1, -100) = 0
f(1, -88) = 0
f(1, 50) = 1
f(1, 100) = 3

# What's the equation behind function f ?

Other hints:
Using 0 as n will always result in 0
Using 0 as w will always result in n

I didn't test many values for n for a reason. If you compare the n as 200, 77 and 1 results to their corresponding n as 100 results I think a clear pattern emerges. With that said if you would like me to test more input comment them below and I will add them to the data above.

If you find an answer that matches most the results but one or two are off, I may have made a transcription error, so do post.

# What is this?

This is a real world puzzle I am trying to solve. Above I tried to break the problem down to its simplest form, but here I will try to explain where it actually comes from.

I have an old piece of Chess software, without source code, that consist of two parts, the Engine and a main Graphical Interface. The Interface can load personality files, and play as say, Bobby Fischer, or Kasparov. The personality files contain variables that are sent to the the engine. One of the variables is the Material/Positional (w above) and reflects whether the engine should value board Positions or Board Material more. There is also an entire set of variables that are sent to the engine to adjust different specific values for positions and pieces. When the Material/Positional variable is adjusted the Interface uses some function (f above) to adjust all the positions values (n above) and adjust all the piece values.

For fun I am trying to build my own replacement interface to work with the original engine. I would like it to be able to load the original personalities from the personality files. This is working fine except I am having trouble reverse engineering the equation used to adjust the position (n) and piece values when the Positional/Material weights (w) change. I could just go load every personality in the interface, as I have a way to see what values are sent to the engine, however, I would prefer to figure out the actual equation for calculating these values.

I'm stuck. I figured someone here might find the the problem interesting.

• It looks like n times some exponential-like function on w, though the "exponential-like" function could be defined in pieces (or even a piecewise linear function). Without access to the executable, we can't really solve it and say "this is how the software implemented that function". If you just need to exactly replicate the function, a viable method is to extract the outputs over all possible input values, and store the entire lookup table in your program. Feb 22 '21 at 2:21
• Yeah, that's a solution. If I could figure out how to automate that process that might work. As is I would have to manually go through all the possible values. It's also not that different than just running every personality and copying the output, which is probably the solution I'll have to do in the end. Feb 22 '21 at 2:35

For guessing a formula on integers, generally we want to start at combinations of inputs that result in "guessable nice numbers". In this case, I look at:

f(100, -100) = 60 = 100 * 3/5
f(100, -50) = 75 = 100 * 3/4
f(100, 0) = 100 = 100 * 3/3
f(100, 50) = 150 = 100 * 3/2
f(100, 100) = 300 = 100 * 3/1

f(200, -100) = 120 = 200 * 3/5
f(200, 50) = 300 = 200 * 3/2
f(200, 100) = 600 = 200 * 3/1


Since the range of w is -100 to 100, which is of length 200 (actually there are 201 numbers, but the idea is there), and every change of 50 of w changes the denominator by 1, we can try with the following formula:

f(n, w) = floor(n * 150 / (150 - w))


And this happens to almost match all values you post here. You can probably adjust the rest by adding a constant C at the end (e.g. C=-0.1) before doing floor.

The mismatched ones that I find weird (from the perspective of the formula above, and these are not the only ones off by one):

f(100, -84) = 64.103 -> actual 64
f(100, -67) = 69.124 -> actual 68


So it might not be based on some simple offset, but since most values are the same, you maybe might want to make exceptions.

• Very cool. This looks pretty promising. I'll test this out this week and see if I can get it to work. Thanks! Feb 22 '21 at 6:07
• The worst mismatches are f(100,95) and f(100,75), which are so far off that they seem likely to be transcription errors. Feb 22 '21 at 9:10
• @JaapScherphuis good point. My guess is that it is the value of w that is imprecise. The listed value is for f(100,94) and f(100,74), respectively. Feb 22 '21 at 10:41