9
int s = 1e9;

What is type of 1e9 and how precise is it? (Is it exactly equal to 1000000000?)

Printing type of a value/variable to stdout would be useful if it's possible.

a-z
  • 1,634
  • 4
  • 16
  • 35
  • 2
    I believe s should be a double, not an int. – duffymo Nov 28 '11 at 14:05
  • Yep, it's double. And you cannot print the type of a variable, C++ doesn't have means for that (I believe it is called reflection). – Violet Giraffe Nov 28 '11 at 14:08
  • 2
    @Violet: Actually, that's a question that [we answered earlier](http://stackoverflow.com/questions/7601533/print-types-of-arbitrary-c-expressions). – MSalters Nov 28 '11 at 15:34

3 Answers3

10

1e9 is a double that has an exact representation in the IEEE floating point representation. The C++ standard doesn't mandate IEEE floating point.

s is an int, so the double value will be automatically converted to an int. How this takes place is to some extent up to the implementation. On most machines nowadays, this conversion means s will be given an initial value of 1000000000.

David Hammen
  • 32,454
  • 9
  • 60
  • 108
  • Why it is equal to 1000000000? If it is the real scientific data, it should be 1.0 x e^9 that is something different, no? What if I need the TRUE scientific value? – TonySalimi Aug 13 '19 at 12:40
  • 3
    @Gupta - 1e9 is short for 1.0 x 10^9, not 1.0 x e^9. The "e" in this context means "base 10 exponent" rather than Euler's number *e* (2.718281828...). – David Hammen Aug 13 '19 at 21:49
5

For what it's worth, you can write code that shows that 1e9 has type double:

#include <iostream>

void show_type(double value) { 
    std::cout << "type = double\n"; 
}
void show_type(...) {
    std::cout << "Type != double\n";
}

int main() { 
    show_type(1e9);
    return 0;
}

Of course, if you don't know what type it has, it's quite a bit more work to provide an overload for every possible type, but the principle is the same nonetheless.

Jerry Coffin
  • 476,176
  • 80
  • 629
  • 1,111
2

If you change it to float or double it's going to be pretty precise, but not every computation with it will be exact (thnks to Kerrek SB), there are limits to precision.

Note, that the precision is not the property of notation, anyway, the notation is the exactness itself.

Michael Krelin - hacker
  • 138,757
  • 24
  • 193
  • 173
  • "You can't do any exact computations" is wrong. The correct statement is that "not *every* computation will be exact". (For example, rational operations where the denominator of the ultimate resulting value is a power of two have a good chance of being exact.) – Kerrek SB Nov 28 '11 at 14:20
  • 1
    @KerrekSB, almost agreed. I'd propose yet another wording: you can not rely on any computation to be exact. But, honestly, I think it is the last paragraph that actually answers the question. – Michael Krelin - hacker Nov 28 '11 at 14:24
  • I don't know. I think you *can* rely on `9.0 / 3.0` to be exactly `3.0`... Why not? – Kerrek SB Nov 28 '11 at 14:25
  • @KerrekSB, well, I wasn't talking about the computation with at least one unknown :) Besides, none of your operands is 1e9 :P – Michael Krelin - hacker Nov 28 '11 at 14:27
  • 1
    Hm, same thing: `double x = 9.0, y = 3.0;` Now the value of `x/y` should be reliably `3.0`, non? My point is that there *are* computations that are indeed exact, and predictably so. (Likewise for `1e9 / 1e8`.) – Kerrek SB Nov 28 '11 at 14:28
  • 1
    True again. It's just that you normally (not always, you're right) don't know if your computations is going to be exact unless you really watch your steps. But well, I'll edit your wording in. – Michael Krelin - hacker Nov 28 '11 at 14:34
  • 1
    There's a certain sense that all operations are exact. Over the set of floating point values, as defined by the floating point processor. The real problem is that floating point numbers aren't real numbers; not only may the result be different than the same operation over real numbers, but many of the basic laws of real number arithmetic, like the associativity of addition, don't hold. – James Kanze Nov 28 '11 at 17:32