Closed davidcastells closed 5 months ago
Floating-point "inexact" means that the rounded result is not the same as the "infinitely precise" result. It basically indicates that the bits which were rounded off were not all zeros.
As Al said, the result is not exactly representable. The fact that squaring the result produces the original input is not proof that the square root was exact. (To see this more easily, consider a two-digit decimal floating-point number representation. If we take sqrt(1.2) in this format, the result will be 1.1, which is obviously inexact. But if we compute 1.1^2, we’d get 1.2 again. So getting the original result back doesn’t mean much.)
The test program is correct.
That's right! Understood. In your example 1.1^2 would be 1.21 that "we" would truncate to 1.2. I am doing a software mode of the processor, and implementing sqrt with Newton-Raphson, so it is easier to check that the infinite precision of the square of the result equals the input value.
You might consider using a library like SoftFloat as a reference model. https://github.com/ucb-bar/berkeley-softfloat-3
Could there be an error in riscv-tests/isa/rv64uf/fdiv.S ?
the 1 in the below macro is to signal an inexact result of the SQRT operation TEST_FP_OP1_S(5, fsqrt.s, 1, 1.7724538498928541, 3.14159265 );
However, the result does not seem to be inexact
3.14159265 = 0x40490FDB 1.7724538498928541 = 0x3FE2DFC5
0x3FE2DFC5 * 0x3FE2DFC5 = 0x40490FDB wich is the original value !! so, why the inexact flag should be activated ??