1

I am not able to understand why the function (log_a_to_base_b) is returning a different value in comparison to the same operation if given with the input values in single line (Please refer below and code for much clearer explanation of problem)

-Basicaly why the function value and the variable x returned values are different as function return type is INT and the x is also storing the answer in INT shouldn't both answer be same

If given the same value The function value in the below code is coming as 3 while the x value in the below code is coming as 2

For refrence the log of 445943744 with base of 764 is 3

// C++ program to find log(a) on any base b
#include <bits/stdc++.h>
using namespace std;

int log_a_to_base_b(int a, int b)
{
    return log2(a) / log2(b);
}

// Driver code
int main()
{
    int a = 445943744;
    int b = 764;
    cout << log_a_to_base_b(a, b) << endl;
    int x=log2(445943744)/log2(764);
    cout<<x<<endl;
    return 0;
}

// This code is contributed by shubhamsingh10, yousefonweb
FSI
  • 17
  • 6
  • Floating-point numbers are imprecise. As `log2` of either of these numbers is impossible to represent in a floating-point type, some rounding errors may and do happen. Compilers typically don't adhere strictly to IEEE-754, so the outcome may depend on your compiler, compilation flags and/or phase of the moon. Or, yes, depending on the surrounding code. – yeputons Oct 30 '22 at 21:28
  • Can't reproduce, both answers are the same for me (`2`): https://godbolt.org/z/qvPTv5o37 – Yksisarvinen Oct 30 '22 at 21:28
  • See [a similar question about C#](https://stackoverflow.com/questions/15490061/why-does-these-two-code-variants-produce-different-floating-point-results), same principles apply in C++. – yeputons Oct 30 '22 at 21:31
  • But shouldnt' the rounding error be happening in both the places in the function and in the x line of code as both are doing exactly same operations and then storing the variable in the Integer data type? @yeputons – FSI Oct 30 '22 at 21:35
  • 1
    @FSI -- "rounding error" is a very misleading term, despite its widespread (mis)use. Forget that you even heard it. – Pete Becker Oct 30 '22 at 21:37
  • 1
    Compilers are allowed to do floating-point calculations at the full precision of the fp unit (typically 80 bits), even when the numbers involved have less precision. Eventually the full-precision value has to be converted to the lower-precision result. Formally, that happens when the value is stored into a variable. But in the code in the question, the result of the fp calculation is never stored; it gets converted to `int`, so it might or might not get adjusted. So, no, doing "the same" floating-point calculation two different ways does not necessarily produce the same result. – Pete Becker Oct 30 '22 at 21:41
  • @FSI It kind of should, but floating-point arithmetic in modern compilers is not deterministic, one good example is described by Pete above, [see details here](https://stackoverflow.com/questions/7517588/different-floating-point-result-with-optimization-enabled-compiler-bug). Do not be misled by the word "optimization" there, even with `-O0` the compiler has to do _something_ with the code which may account as "optimization". – yeputons Oct 30 '22 at 21:43
  • Does this answer your question? [Is floating point math broken?](https://stackoverflow.com/questions/588004/is-floating-point-math-broken) Specifically assigning `2.999999....` to in `int` truncates to `2`. Change all the `int`s to `double`s. - live - https://godbolt.org/z/Pscdc33ov – Richard Critten Oct 30 '22 at 21:45
  • Also @yeputons this resolves my doubt as well as what explained by Pete – FSI Oct 30 '22 at 22:01
  • 1
    @yeputons -- from the compiler's perspective, floating-point arithmetic is fully deterministic. The result of every operation is well-defined and unique. But the compiler is allowed to rearrange operations in ways that do not necessarily produce the same result, so to users who don't know about that, it's mysterious. I'm not disagreeing with what you said, just with "not deterministic", which is far too pessimistic. But not as bad as the assertion I've seen too many times that the low bits of floaint-point calculations are "random". – Pete Becker Oct 30 '22 at 22:03
  • 1
    @PeteBecker I consider it "non-deterministic" in a sense that it's impossible to predict the exact result without compiling the program first and inspecting the assembly. – yeputons Oct 30 '22 at 22:05
  • 1
    @yeputons Non-determinism means it is not possible for ANY form of analysis to predict what the behaviour will be. The fact you (and you're not alone) lack sufficient knowledge (e.g. of transformations of the code done by the compiler, what instructions it outputs, the order of instructions it outputs, and the interactions that come from that) to perform the analysis does qualify something as non-deterministic. – Peter Oct 31 '22 at 00:23

0 Answers0