Brute force is actually quite fast if you avoid pointless calculations.

In the worst case you have 2^(N-1) operators and N!(N-1)! ways of choosing the pairs of numbers for the N-1 operations. So for example, for N=4, this gives 1,152 possibilities.

But you can cut this down substabtially: if you are going to look at 6+2 and 6*2, then there is no need to look at 2+6 and 2*6: just do the bigger number first. This takes out a factor of 2^(N-1) bringing the number of possibilities down to N!(N-1)!, so 144 for N=4.

There are further possible savings as (20+6)+2 is the same as 20+(6+2), but I suspect this may not be worth optimising for until N becomes large. Another is that multiplication by 1 does not help much: this kind of thing may not be a saving with N=4, but could be if you were also for example looking at division (especially if the smaller number is not a factor or divisor of the larger number) as you can then remove a bunch of possibilities. rzzzwilson's suggestion of stopping when the target is exceeded works in a similar way, though only works if the all the operations are non-decreasing (i.e addition and multiplication but not subtraction or division)

As an illustration of something similar, try my old Java applet here, with six numbers and four operators. You can put your own numbers and target in the box. It is not prettily programmed, but is still quite quick.

As you already suggest in your question, there is a big difference between implementing a formula, and implementing a calculation routine. Your paper solution is a routine, not a formula.

• You needed paper to write down numbers as intermediate results. Your algorithm will need something similar. Algorithms for solving systems of equations typically manipulate a matrix (2D array) of numbers. Put your equation factors into an 2D array, and try to describe the substitions as an operation on that matrix.

• When solving this on paper, you take decisions along the way. Eg. You choose to combine the first and third equation and solve that towards R. Then you used the second equation to solve p. This will not always work if there are some 0 factors in your equation. You might need to solve towards another variable, or combine the equations in a different order. The algorithm needs to take into account all these scenarios.

• Your problem is 'overdetermined': In general, 2 lines in 3D will not intersect. It will require a 'lucky shot' (special case) for them to intersect. Your paper example happens to have a solution. And it happens to be round numbers: easy to check. What if your first solution for P would be 1.0 and your second solution would be 0.9999999? Would that be a rounding error of the algorithm, or would the problem have no solution?