Thread: Why tan(1.5708) in radian returns 16331239353195370.00?

Hello to all,

I was doing a simple trig problem in c where i ran across this problem. I was expecting NaN since tan(90 in deg or 1.5708 in rad) is 1/0 . But to my surprise i got 16331239353195370.00 . I admit its been 3 years since i code in c .

What should i do?

Hello,

math - tan() in Java returning a strange value - Stack Overflow
I know this is Java but the reason given holds for 'C'.

Quote:-
Well, tan(pi/2) in radians is essentially infinite, isn't it? So you'd expect to get a very large number, wouldn't you? (It's not infinity because pi/2 can't be exactly represented as a double.

Google search on 16331239353195370 throws up lots of results.

Regards

Originally Posted by mad-hatter

Hello,

math - tan() in Java returning a strange value - Stack Overflow
I know this is Java but the reason given holds for 'C'.

Quote:-
Well, tan(pi/2) in radians is essentially infinite, isn't it? So you'd expect to get a very large number, wouldn't you? (It's not infinity because pi/2 can't be exactly represented as a double.

Google search on 16331239353195370 throws up lots of results.

Regards

Thank you for the reply. The given thread does explain the reason.
However, how should i implement it in c so i get nan or 1/0 or something expected?

π/2 radians cannot be expressed as an exact real number, so you're passing an approximation to tan(). This results in a value on the curve somewhere approaching tan(π/2).

What Every Computer Scientist Should Know About Floating-Point Arithmetic

One solution would be to check the value, and if it's within close proximity to π/2, refrain from performing the calculation - just as it's good practice to ensure a denominator is not zero before performing division.

Originally Posted by mad-hatter

or maybe something like:-

Code:

if (myNumber == 16331239353195370)
{
    //do something)
}

I would avoid this approach.

1. Comparing real types with == does not usually work out well.
2. The actual result in this situation can vary depending on many different factors, so it's not a portable solution.