#### Do you have a question? Post it now! No Registration Necessary

**posted on**

- Thomas Magma

September 1, 2004, 4:38 pm

Hi,

I just wrote some DSP code in Java and ported it over to EVC for a PDA.

Apparently EVC has a problem with the sin() of large numbers. What's up with

this? I need to sin() large numbers. Any suggestions?

Am I the only one that thinks that C, C++, and the MS foundation classes are

a mess, and should be abolished?

Thomas

I just wrote some DSP code in Java and ported it over to EVC for a PDA.

Apparently EVC has a problem with the sin() of large numbers. What's up with

this? I need to sin() large numbers. Any suggestions?

Am I the only one that thinks that C, C++, and the MS foundation classes are

a mess, and should be abolished?

Thomas

Re: Why isn't math universal?

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: Why isn't math universal?

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.

--

Grant Edwards grante Yow! .. I'm IMAGINING a

at sensuous GIRAFFE, CAVORTING

Grant Edwards grante Yow! .. I'm IMAGINING a

at sensuous GIRAFFE, CAVORTING

We've slightly trimmed the long signature. Click to see the full one.

Re: Why isn't math universal?

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

--

"it's the network..." "The Journey is the reward"

snipped-for-privacy@interlog.com Info for manufacturers: http://www.trexon.com

"it's the network..." "The Journey is the reward"

snipped-for-privacy@interlog.com Info for manufacturers: http://www.trexon.com

We've slightly trimmed the long signature. Click to see the full one.

Re: Why isn't math universal?

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.

--

Richard

Richard

Re: Why isn't math universal?

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.

--

Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)

Even if all the snow were burnt, ashes would remain.

Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)

Even if all the snow were burnt, ashes would remain.

Re: Why isn't math universal?

[Please don't top-post&full-quote blindly. Fixed.]

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.

--

Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)

Even if all the snow were burnt, ashes would remain.

Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)

Even if all the snow were burnt, ashes would remain.

Re: Why isn't math universal?

On Wed, 01 Sep 2004 18:09:26 GMT, "Thomas Magma"

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?

[1]"What Every Computer Scientist Should Know About Floating Point

Arithmetic" available in many locations on the web. Google is your

friend.

Regards,

-=Dave

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?

[1]"What Every Computer Scientist Should Know About Floating Point

Arithmetic" available in many locations on the web. Google is your

friend.

Regards,

-=Dave

--

Change is inevitable, progress is not.

Change is inevitable, progress is not.

Re: Why isn't math universal?

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

Re: Why isn't math universal?

Knuth, in his volume on floating point arithmetic, has a very good

discussion and has methods of computing the possible and probable

errors.

--

A: Because it fouls the order in which people normally read text.

Q: Why is top-posting such a bad thing?

A: Because it fouls the order in which people normally read text.

Q: Why is top-posting such a bad thing?

We've slightly trimmed the long signature. Click to see the full one.

Re: Why isn't math universal?

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

Re: Why isn't math universal?

On Wed, 01 Sep 2004 16:38:47 GMT, "Thomas Magma"

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

24 bits and if you have a value around 1E6, the integer part requires

about 20 bits and only 4 bits is available for the decimal part, thus

you can have arguments at about every ten degrees only. You can not

represent any angle in between.

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

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

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

24 bits and if you have a value around 1E6, the integer part requires

about 20 bits and only 4 bits is available for the decimal part, thus

you can have arguments at about every ten degrees only. You can not

represent any angle in between.

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

#### Site Timeline

- » Reverse current into a lithium battery
- — Next thread in » Embedded Programming

- » Communication with a cell phone.
- — Previous thread in » Embedded Programming

- » Atmel 328 ext. interupts
- — Newest thread in » Embedded Programming

- » Jumper Cable FFC/FPC
- — The site's Newest Thread. Posted in » Electronics (Polish)

- » Flugfunk - VOR-Antenne
- — The site's Last Updated Thread. Posted in » Electronics (German)