Is there a value of type `double`, `K`, such that `K * K == 3.0`?

The answer is no; there is no such K.

The closest binary64 value to the actual square root of 3 is equal to 7800463371553962 × 2^-52. Its square is:

60847228810955004221158677897444 × 2^-104

This value is not exactly representable. It falls between (3 - 2^-51) and 3, which are respectively equal to

60847228810955002264642499117056 × 2^-104

and

60847228810955011271841753858048 × 2^-104

As you can see, K * K is much closer to 3 - 2^-51 than it is to 3. So IEEE 754 requires the result of the operation K * K to yield 3 - 2^-51, not 3. (The compiler might convert K to an extended-precision format for the calculation, but the result will still be 3 - 2^-51 after conversion back to binary64.)

Furthermore, if we go to the next representable value after K in the binary64 format, we will find that its square is closest to 3 + 2^-51, which is the next representable value after 3.

This result should not be too surprising; in general, incrementing a number by 1 ulp will increment its square by roughly 2 ulps, so you have about a 50% chance, given some value x, that there is a K with the same precision as x such that K * K == x.

The C standard does not dictate the default rounding mode. While it is typically round-to-nearest, ties-to-even, it could be round-upward, and some implementations support changing the mode. In such case, squaring 1.732050807568877193176604123436845839023590087890625 while rounding upward produces exactly 3.

#include <fenv.h>
#include <math.h>
#include <stdio.h>

#pragma STDC FENV_ACCESS ON


int main(void)
{
    volatile double x = 1.732050807568877193176604123436845839023590087890625;
    fesetround(FE_UPWARD);
    printf("%.99g\n", x*x);  // Prints “3”.
}

x is declared volatile to prevent the compiler from computing x*x at compile-time with a different rounding mode. Some compilers do not support #pragma STDC FENV_ACCESS but may support fesetround once the #pragma line is removed.

Testing with Python is valid I think, since both use the IEEE-754 representation for doubles along with the rules for operations on same.

The closest possible double to the square root of 3 is slightly low.

>>> Sqrt3 = 3**0.5
>>> Sqrt3*Sqrt3
2.9999999999999996

The next available value is too high.

>>> import numpy as np
>>> Sqrt3p = np.nextafter(Sqrt3,999)
>>> Sqrt3p*Sqrt3p
3.0000000000000004

If you could split the difference, you'd have it.

>>> Sqrt3*Sqrt3p
3.0

In the Ruby language, the Float class uses "the native architecture's double-precision floating point representation" and it has methods named prev_float and next_float that let you iterate through different possible floats using the smallest possible steps. Using this, I was able to do a simple test and see that there is no double (at least on x86_64 Linux) that meets your criterion. The Ruby interpreter is written in C, so I think my results should be applicable to the C double type.

Here is the Ruby code:

x = Math.sqrt(3)
4.times { x = x.prev_float }
9.times do
  puts "%.20f squared is %.20f" % [x, x * x]
  puts "Success!" if x * x == 3
  x = x.next_float
end

And the output:

1.73205080756887630500 squared is 2.99999999999999644729
1.73205080756887652704 squared is 2.99999999999999733546
1.73205080756887674909 squared is 2.99999999999999822364
1.73205080756887697113 squared is 2.99999999999999866773
1.73205080756887719318 squared is 2.99999999999999955591
1.73205080756887741522 squared is 3.00000000000000044409
1.73205080756887763727 squared is 3.00000000000000133227
1.73205080756887785931 squared is 3.00000000000000177636
1.73205080756887808136 squared is 3.00000000000000266454

Is there a value of type double, K, such that K * K == 3.0?

Yes.

K = sqrt(n); and K * K == n may be true, even when √n is irrational.

Note that K, the result of sqrt(n), as a double, is a rational number.

• Various rounding modes: @Eric

• K * K rounds to n

Example: Roots n: 11, 14 and 17 when squared are n.

for (int i = 10; i < 20; i++) {
  double x = sqrt(i);
  double y = x * x;
  printf("%2d %.25g\n", i, y);
}

10 10.00000000000000177635684
11 11
12 11.99999999999999822364316
13 12.99999999999999822364316
14 14
15 15.00000000000000177635684
16 16
17 17
18 17.99999999999999644728632
19 19.00000000000000355271368

• Different precision

Rather than 53 bits with common double, say the FP math was done with 24. Roots n: 3, 5 and 10 when squared are n.

for (int i = 2; i < 11; i++) {
  float x = sqrtf(i);
  printf("%2d  %.25g\n", i, x*x);
}

 2  1.99999988079071044921875
 3  3
 4  4
 5  5
 6  6.000000476837158203125
 7  6.999999523162841796875
 8  7.999999523162841796875
 9  9
10  10

or say the FP math was done with 64 bits. Roots n: 5, 6 and 10 when squared are n.

for (int i = 2; i < 11; i++) {
  long double x = sqrtl(i);
  printf("%2d  %.35Lg\n", i, x*x);
}

 2  1.9999999999999999998915797827514496
 3  3.0000000000000000002168404344971009
 4  4
 5  5
 6  6
 7  6.9999999999999999995663191310057982
 8  7.9999999999999999995663191310057982
 9  9
10  10

With various precisions, (note C does not specify a fixed precision), K * K == 3.0 is possible.

• FLT_EVAL_METHOD == 2

When FLT_EVAL_METHOD == 2, intermediate calculations may be done at higher precession, thus affecting the product of k*k.

(Have yet to come up with a good simple example.)

sqrt(3) is irrational, which means that there is no rational number k such that k*k == 3. A double can only represent rational numbers; therefore, there is no double k such that k*k == 3.

If you can accept a number that is close to satisfying k*k == 3, then you can use std::numeric_limits (in <type_traits>, if memory serves) to see if you’re within some minimal interval around 3. It may look like:

assert( abs(k*k - 3.) <= abs(k*k + 3.) * std::numeric_limits<double>::epsilon * X);

Epsilon is the smallest difference from one that double can represent. We scale it by the sum of the two values to compare in order to bring its magnitude in line with the numbers we’re checking. X is a scaling factor that lets you adjust the precision you accept.

If this is a theoretical question: no. If it’s a practical question: yes, up some level of precision.