Why do I get a very small number when evaluating 1 normSin?

Question

I wanted to do a few experiments with complex multiplication building resonators and filters but it appears that the sin, normSin, cos and normCos messages don't output 0 although they should. Also I get different results using the normalized messages compared to the messages based on Pi (1 normSin gives you a different result than Double pi sin - see example below). This might be a rounding error, but since my calculator can do it I suppose Kyma should do it as well ;)

Here's a little script to show it:

"Sin/Cos not evaluating to zero"
| resultSin resultNormSin resultCos resultNormCos |

resultSin := (Double pi) sin.
self debugWithLabel: 'Sin(Pi)' value: resultSin.

resultNormSin := 1 normSin.
self debugWithLabel: '1 normSin' value: resultNormSin.

resultCos := (0.5 * Double pi) cos.
self debugWithLabel: 'Cos(Pi/2)' value: resultCos.

resultNormCos := 0.5 normCos.
self debugWithLabel: '0.5 normCos' value: resultNormCos.

It might be that those small numbers are neglectable. On the other hand a small numbers can make huge differences here.

Thanks!

 

Answer 1

On the computer, transcendental functions have to be approximated, and π , being an irrational number, is also an approximation. Since this means that the computer's version of π is slightly different than the "real" value of π, the computed value of sin(π) will also be different than the "real" value of 0.

If your calculator is giving zero as the result, it may be because the calculator has fewer bits of precision or is checking for this special case. If you like, you can do the same in your calculations.

Here is a detailed explanation of each of your expressions:

1. If you do the same sine of π calculation in C, the result is the same as in Kyma:

sin pi = 1.22465e-16

Smalltalk and C use the same float and double libraries, so this is not a surprise. 64-bit double precision floating point numbers have a 48 bit mantissa; this means that the precision of any result is 3.5527136788005d-15.

2. If, instead of 1 normSin, you use 1.0d normSin, you will get more precision, since you are sending the message to a Double instead of an Integer.

3. Again, the same result in Smalltalk and C:

cos pi/2 = 6.12323e-17

4. If, instead of 0.5 normCos, you use 0.5d normCos, you will get more precision, since you are sending the message to a Double instead of a Float.

 

Comments

I see, thanks for the insight! It's totally clear that there's no exact representation of pi. apart from the limits of digital numbers we don't even know yet how many digits we would need ;) I guess my calculator is checking for that case..

---

very interesting thanks SSC