Brute-force search for solution to an unsolved mathematical inequality

From this Wikipedia article, the following unsolved problem is presented as a
result of Waring's problem:

2^{k}-\left\lfloor \left({\tfrac {3}{2}}\right)^{k}\right\rfloor -2}">

It has been proven that a finite number of k exist, and so far none are known. The follow code is meant to brute-force search for a solution:

#include
//#include
#include

typedef boost::multiprecision::number> arbFloat;

enum returnID {success = 0, precisionExceeded = 1};

int main(){
arbFloat k;

for(k = 6; pow(3, k) - (pow(2, k) * floor(pow(1.5, k)))

I am using the Boost multiprecision library cpp_dec_float, which works for large integers and decimals. The data type needs to be able to work with integers, because the solution for k needs to be a positive integer. The data type needs to work with decimals because (3/2)^k (equivalently 1.5^k) returns a decimal.

In the code I have commented out the cmath library, because it appears to be included in boost/multiprecision/cpp_dec_float.

In the for-loop, I use .

After the for-loop, I re-check if it is a solution because currently if the precision is exceeded, it breaks the for-loop. The if-else checks if it is has either exceeded precision or is an actual solution.

The precision in this example code is 1000 (line 5), but this is changed manually as I search for larger and larger numbers that may be a solution.

I am trying to squeeze every ounce of speed out of this code, so any optimizations that make it quicker will be of great help!

I am running this code on Ubuntu 16.04, and I compile it using g++ with the -Ofast` flag for the highest possible optimization during compilation.

Thanks!

A first step in optimizing would be to avoid computing the same values multiple times.

Secondly, I would drop the floating point arithmetic altogether. You have integer bases with integer exponents, so use integers. \$(\frac{3}{2})^k\$ = \$\frac{3^k}{2^k}\$ and applying floor also results in an integer.

I'm not familiar with the problem at hand, but the mention that none are known leads me to think that the values might be quite higher than 1000, otherwise a solution would have been trivial to find.

StackExchange Code Review Q#156319, answer score: 5