Recently, I wrote a program that at one stage had to calculate the square of a number. I saw that sometimes I got strange results. I was using the sqr function in Delphi. Upon closer inspection I discovered that when you input an integer to sqr, its output was an integer too. This means that you might get in trouble if the square of your input exceeds Delphi's integer limit which is (2^31)-1 or 2147483647 (a 32 bit number).
Normally one would expect the sqr function to throw an exception in case of an overflow. As a matter of fact, if you try to evaluate X*X where X=100000, you get an "integer overflow" complaint from the compiler because X*X=1e10 which is larger than (2^31)-1. However, if you use sqr(X) instead, the compiler happily calculates the result as... 1410065408! The sqr function does not catch integer overflows, instead, it provides the result that fits in 32 slots. Id est, it discards the remaining bits.
Let me explain: 1e10 is 1001010100000010111110010000000000 in binary. This is a number that requires 34 bits. However, integer has only 32 bits. So you kiss goodbye to the 33rd and 34th bits which leaves you with 01010100000010111110010000000000 which is... voila... 1410065408, exactly the result that sqr(X) gave us.
I advise to use the power function to be safe because power(X,2) gives the correct results.
Moral of the story: Always use functions like sqr, sqrt, cos, atan with extreme caution. Be sure to have explicit tests that just verify those functions, especially off limits.
You can download the executable and the source code of my little Delphi program if you don't believe me ;)