It's not about the digits in your pi. It's just the way sin() function works, not much you can do about it. If you really want the 0.0, write an if

1.22461e-16 is equal to 0.000000000000000122461, which is pretty close to 0 if you ask me. This is just caused by the precision of the double type and how the data is stored. You could also round the number to remove that problem.

It's in the nature of finite precision.
Theres not much you can do about it.

there a basicly two kinds of datatypes.
1. integral
2. float

integral being, int, char, byte etc
floats being, float, double

integral is always precise, floating values are more obscure

What numerical libraries do is to check for equality within a tolerance like

If you need it depends on your context,
if you just want the value, then you shouldn't care.

But if your program has a branchpoint depending on this value,
you should go the "within tolerance" way.

on a sidenote.
floats are only precise to the 7th or 8th digit,
whereas double are to the 23thd

good luck

May be you still remember (from a school math course) that no fractions which are equal to pi number.
Other post correction: double type provide ~16 decimal digits precision (53 bits of mantissa).

And you should really include <cmath> instead.

Your output is expected, and here's the result of the same when I tried it on Wolfram's Online Math Engine.

Here: The sin() function prototypes

Ah I see. It's just odd that the cosine of an approximation of pi does return -1, but it's probably just something about the way the math library works.
Anyhow, thanks all!

>It's just odd that the cosine of an approximation of pi does return -1
Exactly!
As usually, math libraries (and FPU hardware) implement high precision (~13-15 decimal digits) polynomial approximations of common math functions.