Why isn't math universal?

Why not use sin( x % TWO_PI ); where TWO_PI is 6.283185..... assuming x is in radians?

Quite impossible to tell, until you specify what "large" is supposed to mean, in this context. From the point of view of the sine function, an argument of 100 may already appear somewhat large, and an argument in anywhere outside the range of +/- 1/DBL_EPSILON will mean there's nothing left to salvage.

Double-check your needs. Carefully.

Could you explain that to me slowly. Are you suggesting that sin(x%*2*pi) = sin(x*2*pi)?

with

are

Well it's giving me the old -1.#IND00 at around sin(220000000.0). Shouldn't the sin of any real number (double) equal something real? Java doesn't have a problem with this.

with

Nor does a 3 dollar calculator!!!

Shouldn't

have

PDA.

up

In a perfect world: yes. Reality doesn't work that way though.

Well, then try sin(1e20) in Java or in your calculator. Does the result remind of something you saw recently?

At full IEEE double-precision floating point (i.e. 52 bits of mantissa precision), sin(1e20) returns "undefined value". So your embedded platform, which quite probably has fewer bits to spare, already freaks out at 2.2e9 --- I can't say that has me particularly surprised. Actually, that's quite exactly the region where I would expect a 32bit mantissa to fail.

The problem is that for a number so large that a single bit step in the mantissa moves the argument by more than one period of the sine function, there *is* no sensible result that could be returned by sin() any more. That's like asking which atom in the floor tiling you would hit as you stamp down your foot.

I think the point was that sin(), by definition, takes an angle - which is conventionally in the range 0-360 degrees. If you're dealing with angles of

using e.g. the modulus function (i.e. "%").

HTH,

Steve

Of course you lose significant digits when you take the sin() of a large number. Especially, since MS stuff is broken so it typically uses 64 bits rather than the 80 bits the FPU is capable of, this may be an issue.

Best regards, Spehro Pefhany

What I meant was that the sin() function repeats for every 2 * pi radians of the input argument so if you take the modulus 2 * pi of the input argument and take the sin() if that you should get the correct answer. I should have said sin( fmod( x, TWO_PI ) ); I used the integer modulus operator (%) in my original post. As someone else pointed out you have a problem with loosing resolution as the angles get very large.

Dave Rooney

re Subject: Math is universal.

Floating point numbers are not the same thing as real numbers. To quote the estimable David Goldberg[1]: "Squeezing infinitely many real numbers into a finite number of bits requires an approximate representation."

Do you know what the sine function is? Do you really have to go around the circle more than 35 million times?

Do you know what IND means?

Regards,

-=Dave

No, he's telling you that for real numbers, by definition

sin(x modulo (2*pi)) == sin(x)

For floating point numbers, results vary depending on the value of x.

Thanks for all the responses. I guess I was just taking for granted that numbers are numbers and math is math.

The perfect world I lived in just came crashing down all around me.

with

are

No doubt you are going to be in trouble taking sin(x) if x is float and x is a few millions. Since the mantissa in the IEEE float is only

If you are going to need double precession for the argument, which usually means more than 50 bits for the mantissa. Assuming you have an int(x) function that will take the integer part (truncate) of a double argument x and return a 32 bit integer value. If the double argument X is positive and less than about 12E9, the following should give a reasonable accuracy.

double frac_x, X, x1, y ;

x1 = X / TWO_PI ; frac_x = x1 - int(x1) ; y = sin(TWO_PI*frac_x) ;

Even at 12E9, there will be about 20 meaningful fractional bits, so you will still get different values for each arc second. If you need larger arguments than 12E9, you need an int function that returns a 64 bit value.

How the negative values of X are handled, should be quite obvious.

While the MFC deserves a lot of criticism, I do not understand why your problems with sin(x) should justify that judgement. I have patched up some mathematical libraries written in assembler, so clearly the language is not an issue in writing bad math functions.

Paul

You should stay away from computers... ;)

Life's like that.

Dave Rooney wrote in news:ch51aj$jt3$ snipped-for-privacy@bluegill.adi.com:

For large numbers, I would expect he will have the same problems doing it this way, due to where the significant digits of the large number are. Even if it's using 80 bits, that's only 19ish significant digits, so once your number starts getting big enough that those 19 significant digits are to the right of the decimal point, or even close to that, you will lose accuracy rapidly.

But the clean ideas in your mind are different from those implemented in computers. You can easily imagine pi as exact, for example, but a computer cannot achieve that, in practice.

The study of this imperfect world uses various numerical methods, which itself is good math to know. There's a book I like called "Numerical Methods for Engineers" you might consider, as a start. It has some very easy to read sections on errors in floating point usage. And keep in mind that in computers things like A*(B+C) does not equal A*B+A*C; or that subtracting two similar magnitude values, A-B, where both A and B may have many bits of precision, may provide a result with very few bits of precision.

Jon

We've all had times when the error of an assumption has been made painfully clear. If you explain the application and/or algorithm, someone here can probably help. In the meantime, I think we can all sympathize :-(

Bob

Knuth, in his volume on floating point arithmetic, has a very good discussion and has methods of computing the possible and probable errors.

The books are: Donald E. Knuth, The Art of Computer Programming:

- Volume 1, Fundamental Algorithms, ISBN 0-201-89683-4, - Volume 2, Seminumerical Algorithms, ISBN 0-201-89684-2, and - Volume 3, Sorting and Searching, ISBN 0-201-89685-0

Tauno Voipio tauno voipio (at) iki fi