1. pow() has overloads, but they all are floating point variations. You can call pow() with integer types; there will be implicit conversion to some floating type. If there are ambiguous cases -- equally "easy" conversion will match two different overloads, then explicit types (or conversions) are needed to resolve the overload. This is least of the problems.
2. Floating point types are strange and weird. Do not expect to do mathematics with them. They don't have enough precision for that. Most definitely you don't want your loop counter
i to be a floating point type. Ever.
3. Yes, you could force conversion from float type into integer type with a cast. However, the syntax
(unsigned long long)foo
is a C-style cast. You should prefer the C++-syntax, so here
static_cast<unsigned long long>(foo)
. However,
4. There is a
bitshift left operator for (unsigned) integers. Moving bits left by X steps is equivalent to multiplying the number by 2^X. Therefore, you could write
(3 + (1 << (i-1)) ) % i
. All integer operation. However,
5.
1 << 99999999998
requires 99999999999 bits. The C++ standard guarantees that
unsigned long long
can hold at least 64 bits. I find it highly unlikely that any compiler and platform would reserve 99999999999 for single integer, when standard demands only 64 and special hardware, like Xeon Phi, has mere 512 bit registers.
That is one big problem. You do need custom "big ints". Some websearch hits:
https://mattmccutchen.net/bigint/
http://stackoverflow.com/questions/269268/how-to-implement-big-int-in-c
Note: you can write an integer version of pow(). It's just a
*= in a
for loop that iterates exponent times.