# Thread: tan(pi/2) = infinity; now try to do this is C

1. ## tan(pi/2) = infinity; now try to do this is C

Can you make "tan()" crash, by passing it pi/2 (which results in infinity)?

I tested it out, with float and double, and I cannot pass it exactly pi/2, so it does not crash. I've also tried pi/2+pi, pi/2+2pi, etc.

Is it possible?

2. well, can you even get an exact pi to divide?

3. Since the double type cannot accurately represent "pi/2", you only get a very large number for the double value slightly below pi/2 and a very large negative number for the double value slightly above pi/2.

Also, in general the math functions will return infinity if passed something that results in an overflow. For example exp(1000).

4. Isn't it supposed to be a good thing that tan() can't crash your program?

5. Originally Posted by cwr
Also, in general the math functions will return infinity if passed something that results in an overflow. For example exp(1000).
Not true.

Only some floating point formats (e.g. IEEE) support the notion of "infinity". There is no requirement that a C compiler employs such a floating point format. The actual definition of floating point in C (or C++) only requires that a floating point represent a value in the form sign*mantissa*10^exponent where ^ represents "to the power of", sign is +/-1, mantissa is in the range 0 to 1, and exponent is a signed integral value. In practice, there are plenty of C compilers that target systems which do not support IEEE or similar floating point formats.

6. I don't know if this make any difference, but tan(pi/2) is not actually inifinity. By definition tan is sin/cos and since the sin of pi/2 is 1 and the cos of pi/2 is 0 the tan of pi/2 is an undefined value, because you cannot divide anything by zero. On the other hand, the limit of x as it approaches tan(pi/2) from the left is infinity.

7. That is true; should tan(pi/2) return infinity, or should it return negative infinity? But of course mathematically pi/2 is not in tan's domain, so saying tan(pi/2) is just nonsense.

8. Originally Posted by CrazedBrit
I don't know if this make any difference, but tan(pi/2) is not actually inifinity. By definition tan is sin/cos and since the sin of pi/2 is 1 and the cos of pi/2 is 0 the tan of pi/2 is an undefined value, because you cannot divide anything by zero. On the other hand, the limit of x as it approaches tan(pi/2) from the left is infinity.
I assume, with the last sentence, you intended to say something like "the limit as x tends to pi/2 from the left of tan (x) is positive infinity".

In addition, "the limit as x tends to pi/2 from the right of tan (x) is negative infinity".

The fact that the left and right limits have different values means that tan(pi/2) has no value (infinite or otherwise).

9. Originally Posted by grumpy
The fact that the left and right limits have different values means that tan(pi/2) has no value (infinite or otherwise).
This kind of statement is in general not true.

10. "Undefined"? Then why didn't they make it like

Code:
```double tan(double x)
{
if(x / PI * 2 == (int)(x / PI * 2))
{
throw exception;
}
}```
?

Ok, mathematically speaking, tan(x) TENDS to infinity as x TENDS to (2K+1)PI/2, but is UNDEFINED for (2k+1)PI/2. The single point. Make sense?

11. Originally Posted by jafet
"Undefined"? Then why didn't they make it like

Code:
```double tan(double x)
{
if(x / PI * 2 == (int)(x / PI * 2))
{
throw exception;
}
}```
?
One explanation is that it's mathematically incorrect. And another is because (as cwr said) PI/2 cannot be precisely represented in floating point, so it is not possible for any floating point value to be exactly equal to pi/2.

Originally Posted by jafet
Ok, mathematically speaking, tan(x) TENDS to infinity as x TENDS to (2K+1)PI/2, but is UNDEFINED for (2k+1)PI/2. The single point. Make sense?
No.

Mathematically, tan(x) is a function with discontinuities at all values x = (2k+1)pi/2 where k is an integer. Those discontinuities exist because cos(x) is zero for all x = (2k+1)pi/2 and because sin(x) is either 1 or -1. And because the cos((2k+1)pi/2 + delta) = -cos((2k+1)pi/2 - delta) --- i.e. cos(x) changes sign as x crosses left to right through (2k+1)pi/2.

12. Um... yeah, that's what I meant, sorry if I wasn't clear.

And the throw-exception-to-annoy-beginners-who-obviously-know-nothing-about-exceptions thing is just a joke

13. Originally Posted by jafet
Isn't it supposed to be a good thing that tan() can't crash your program?
This is all I really wanted to know. I can check to see if the result is finite, if it is not then I can handle it and make sure my program doesn't crash. I believe this is the solution I was looking for, and I am satisfied with it.

14. Originally Posted by MatthewDoucette
Can you make "tan()" crash, by passing it pi/2 (which results in infinity)?
Oh, and sorry about the "results in infinity", as I knew it was actually undefined (as it approaches both positive and negative infinity depending on which direction to approach it from.) I should have been more technically accurate!

I am not sure what MSVC++ would return IF I could pass tan() pi/2 perfectly somehow. For now, I have just been checking the results to be finite or not, and if they are non-finite I cannot use them and handle the problem appropriately.

15. Originally Posted by grumpy
Not true.

Only some floating point formats (e.g. IEEE) support the notion of "infinity". There is no requirement that a C compiler employs such a floating point format. The actual definition of floating point in C (or C++) only requires that a floating point represent a value in the form sign*mantissa*10^exponent where ^ represents "to the power of", sign is +/-1, mantissa is in the range 0 to 1, and exponent is a signed integral value. In practice, there are plenty of C compilers that target systems which do not support IEEE or similar floating point formats.
C only supports floating point operations (IEEE format or whatever else). If you want fixed point operations, you have to implement it yourself. Also, IEEE format is sign * mantissa *2^exponent. Remember, its base 2, not base 10.