Morten Welinder writes: > > But, you are using a number in the range of 2^90, only > > have 64 bits for storing the floating point representation, and > > some of that is needed for the exponent. > > 2^90 would require 91 bits for the base alone (as an integer > > value), plus a couple more for the '*PI' portion, and then > > more for the exponent. And that wouldn't include anything > > past the decimal point. > > You are more than 30 bits short of getting a crappy result. > > This is not right. > > Floating point variables are perfectly capable of holding _some_ > rather large floating point numbers completely accurately. The > integer 2^90 is one of them (on a standard base-2 machine). > > It is true that its nearest neighbours are about 2^30 away, but > that is not relevant for the accuracy of 2^90. pow(2.0,90.0) > generates that value with no error. > > Therefore sin(2^90) is a well defined number somewhere between -1 and 1 > and the C fragment > > sin(pow(2.0,90.0)) > > should calculate it with at most one wrong bit at the end. (You > get a one-bit allowance since "sin" is trancendental.) > > Morten
> (who wouldn't be too surprised if some "sin" implementations failed > to do that) Me either. gcj, which has its own floating-point library, gets this right: System.out.println(Math.sin(Math.pow(2.0, 90.0))); -0.9044312486086016 whereas gcc gets it wrong, at least on my GNU/Linux box: printf ("%g %g\n", pow (2.0, 90.0), sin (pow (2.0, 90.0))); 1.23794e+27 -0.00536134 sin (2^90) is, approximately: -.90443124860860158093619738795260971475 Andrew.