>
> 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
Reply by CBFalconer●September 1, 20042004-09-01
Jonathan Kirwan wrote:
> "Thomas Magma" <somewhere@overtherainbow.com> wrote:
>
>> Thanks for all the responses. I guess I was just taking for
>> granted that numbers are numbers and math is math.
>
> 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 perfect world I lived in just came crashing down all around
>> me.
>
> 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.
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: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Reply by Bob●September 1, 20042004-09-01
"Thomas Magma" <somewhere@overtherainbow.com> wrote in message
news:A3qZc.293762$J06.274236@pd7tw2no...
> 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.
>
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
Reply by Jonathan Kirwan●September 1, 20042004-09-01
>Thanks for all the responses. I guess I was just taking for granted that
>numbers are numbers and math is math.
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 perfect world I lived in just came crashing down all around me.
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
Reply by Richard●September 1, 20042004-09-01
Dave Rooney <rooney@adi.com> wrote in
news:ch51aj$jt3$1@bluegill.adi.com:
>
>
> Thomas Magma wrote:
>
>> 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
>>
> Why not use sin( x % TWO_PI ); where TWO_PI is 6.283185.....
> assuming x is in radians?
>
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
Reply by Grant Edwards●September 1, 20042004-09-01
On 2004-09-01, Thomas Magma <somewhere@overtherainbow.com> wrote:
> Thanks for all the responses. I guess I was just taking for
> granted that numbers are numbers and math is math.
You should stay away from computers... ;)
> The perfect world I lived in just came crashing down all around me.
Life's like that.
--
Grant Edwards grante Yow! There's a lot of BIG
at MONEY in MISERY if you have
visi.com an AGENT!!
Reply by Paul Keinanen●September 1, 20042004-09-01
>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?
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.
>Am I the only one that thinks that C, C++, and the MS foundation classes are
>a mess, and should be abolished?
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
Reply by Thomas Magma●September 1, 20042004-09-01
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.
"Thomas Magma" <somewhere@overtherainbow.com> wrote in message
news:rWmZc.279639$M95.264941@pd7tw1no...
> 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
>
>
Reply by Grant Edwards●September 1, 20042004-09-01
On 2004-09-01, Thomas Magma <somewhere@overtherainbow.com> wrote:
>> Why not use sin( x % TWO_PI ); where TWO_PI is 6.283185..... assuming
>> x is in radians?
> Could you explain that to me slowly. Are you suggesting that
> sin(x%*2*pi) = sin(x*2*pi)?
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
visi.com in the BACK ROOM of a
KOSHER DELI --
Reply by Dave Hansen●September 1, 20042004-09-01
On Wed, 01 Sep 2004 18:09:26 GMT, "Thomas Magma"
<somewhere@overtherainbow.com> wrote:
re Subject: Math is 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.
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.