Why isn't math universal?

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

Translate This Thread From English to

•  Subject
• Author
• Posted on
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

Re: Why isn't math universal?

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

Re: Why isn't math universal?
Could you explain that to me slowly. Are you suggesting that sin(x%*2*pi) =
sin(x*2*pi)?

with
are

Re: Why isn't math universal?

=

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
http://www.fivetrees.com

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
We've slightly trimmed the long signature. Click to see the full one.
Re: Why isn't math universal?
On Wed, 01 Sep 2004 13:36:18 -0400, the renowned Dave Rooney

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
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

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.

--
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?
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

Re: Why isn't math universal?
Nor does a 3 dollar calculator!!!

Shouldn't
have
PDA.
up

Re: Why isn't math universal?

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.

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
--
Change is inevitable, progress is not.

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

Re: Why isn't math universal?

You should stay away from computers... ;)

Life's like that.

--
Grant Edwards                   grante             Yow!  There's a lot of BIG
at               MONEY in MISERY if you have
We've slightly trimmed the long signature. Click to see the full one.
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?
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?

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

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_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