29

I was reading Setting an int to Infinity in C++. I understand that when one needs true infinity, one is supposed to use numeric_limits<float>::infinity(); I guess the rationale behind it is that usually integral types have no values designated for representing special states like NaN, Inf, etc. like IEEE 754 floats do (again C++ doesn't mandate neither - int & float used are left to the implementation); but still it's misleading that max > infinity for a given type. I'm trying to understand the rationale behind this call in the standard. If having infinity doesn't make sense for a type, then shouldn't it be disallowed instead of having a flag to be checked for its validity?

Community
  • 1
  • 1
legends2k
  • 31,634
  • 25
  • 118
  • 222
  • 7
    Are you sure that `numeric_limits::has_infinity` is `true`? If it's not, then the standard doesn't require `infinity()` to be meaningful. – Angew is no longer proud of SO Dec 13 '12 at 14:14
  • 1
    http://en.cppreference.com/w/cpp/types/numeric_limits/has_infinity – BoBTFish Dec 13 '12 at 14:15
  • 1
    Yep, like I mentioned in the question, one cannot represent infinity using an integer value because of its inherent nature, but still a Joe coder not knowing `has_infinity()` trying out the above line will shoot his foot nice and square; it seems unintuitive. – legends2k Dec 13 '12 at 14:20
  • 1
    Most answers say the same thing mentioned in the question, but not the actual rationale; say why did the standards committee, instead of giving a `has_infinity()`, didn't opt for not defining `infinity()` for such types? – legends2k Dec 13 '12 at 14:27
  • @legends2k: It is not `has_infinity()`, it is just `has_infinity`. It is not a function. – Nawaz Dec 13 '12 at 14:34
  • 3
    @legends2k: I agree with you. If this function doesn't return any meaningful value, then it should not exist, or at least require the implementation *to reject the code on using this function*. That is not that difficult. With the help of some metaprograming, the implementation could detect meaningless usage. But then I think such techniques was discovered later. – Nawaz Dec 13 '12 at 14:42
  • 1
    @Nawaz Oh yes, just noticed that has_infinity isn't a function, thanks! And yes again, one could've avoided it with SFINAE. – legends2k Dec 13 '12 at 14:51
  • 1
    “Integral types are finite”, *as are* floating-point types—floats trade precision for range, and merely have additional special representations for positive and negative infinity, signed zero, and NaN. – Jon Purdy Dec 13 '12 at 18:34
  • @JonPurdy Agreed, fixed it in the question, thanks! – legends2k Mar 19 '15 at 01:54

4 Answers4

35

The function numeric_limits<T>::infinity() makes sense for those T for which numeric_limits<T>::has_infinity returns true.

In case of T=int, it returns false. So that comparison doesn't make sense, because numeric_limits<int>::infinity() does not return any meaningful value to compare with.

Nawaz
  • 353,942
  • 115
  • 666
  • 851
  • 9
    In fact, the standard _requires_ non-meaningful values to be `0` or `false`. – James Kanze Dec 13 '12 at 14:22
  • 2
    Why are we even allowed to make comparisons that don't make sense? Why not fail at compile time if someone tries to use `numeric_limits::infinity()`? – eddi Aug 03 '17 at 20:23
6

If you read e.g. this reference you will see a table showing infinity to be zero for integer types. That's because integer types in C++ can't, by definition, be infinite.

Some programmer dude
  • 400,186
  • 35
  • 402
  • 621
5

Suppose, conversely, the standard did reserve some value to represent inifity, and that numeric_limits<int>::infinity() > numeric_limits<int>::max(). That means that there would be some value of int which is greater than max(), that is, some representable value of int is greater than the greatest representable value of int.

Clearly, whichever way the Standard specifies, some natural understanding is violated. Either inifinity() <= max(), or there exists x such that int(x) > max(). The Standard must choose which rule of nature to violate.

I believe they chose wisely.

Robᵩ
  • 163,533
  • 20
  • 239
  • 308
  • 2
    There is a third option: require the implementation to reject the code which uses `numeric_limits::infinity()` - which is possible with a bit of metaprogramming. – Nawaz Dec 13 '12 at 14:47
  • @Robᵩ This seems to be right; although I'd say, like Nawaz suggested, this could've been avoided for types which don't have an infinity representation using SFINAE, but I guess these functions were defined earlier than meta-programming's advent. – legends2k Dec 30 '12 at 02:07
  • Also this shows that the language projects what the machine does as is, which, in my opinion, isn't great because later suppose some novel machine's architecture does support infinity for integral types, then its `has_infinity` would be true, and hence it's the programmer who has to add another exception to his mental model. This is exactly what makes C++ expert-friendly and complex for the Joe coder. – legends2k Dec 30 '12 at 02:14
0

numeric_limits<int>::infinity() returns the representation of positive infinity, if available.

In case of integers, positive infinity does not exists: 

cout << "int has infinity: " << numeric_limits<int>::has_infinity << endl;

prints 

int has infinity: false
higuaro
  • 15,730
  • 4
  • 36
  • 43