Re: Sine and Cosine Accuracy

On 31/05/2005, at 6:34 AM, Paul Koning wrote: "Geoffrey" == Geoffrey Keating <[EMAIL PROTECTED]> writes: Geoffrey> Paul Koning <[EMAIL PROTECTED]> writes: After some off-line exchanges with Dave Korn, it seems to me that part of the problem is that the documentation for -funsafe-math-opti

Re: Sine and Cosine Accuracy

> "Geoffrey" == Geoffrey Keating <[EMAIL PROTECTED]> writes: Geoffrey> Paul Koning <[EMAIL PROTECTED]> writes: >> After some off-line exchanges with Dave Korn, it seems to me that >> part of the problem is that the documentation for >> -funsafe-math-optimizations is so vague as to have no

Re: Sine and Cosine Accuracy

On 2005-05-30 11:51:59 -0400, Scott Robert Ladd wrote: > The fact that trigonometric functions can extended beyond 2D geometry in > no way invalidates their use in their original domain. I've written many > 2D and 3D applications over the years without need for a sine outside > the range [0, 2*PI]

Re: Sine and Cosine Accuracy

Scott Robert Ladd writes: > chris jefferson wrote: > > I would like to say yes, I disagree that this should be true. By your > > argument, why isn't sin(pow(2.0,90.0)+1) == sin(6.153104..)? Also, how > > the heck do you intend to actually calculate that value? You can't just > > keep subtracti

Re: Sine and Cosine Accuracy

chris jefferson wrote: > I would like to say yes, I disagree that this should be true. By your > argument, why isn't sin(pow(2.0,90.0)+1) == sin(6.153104..)? Also, how > the heck do you intend to actually calculate that value? You can't just > keep subtracting multiples of 2*pi from pow(2.0, 90.0)

Re: Sine and Cosine Accuracy

chris jefferson writes: > Scott Robert Ladd wrote: > > >Marc Espie wrote: > > > > > >>Heck, I can plot trajectories on a sphere that do not follow great circles, > >>and that extend over 360 degrees in longitude. I don't see why I should be > >>restricted from doing that. > >> > >

Re: Sine and Cosine Accuracy

Scott Robert Ladd wrote: Marc Espie wrote: Heck, I can plot trajectories on a sphere that do not follow great circles, and that extend over 360 degrees in longitude. I don't see why I should be restricted from doing that. Can you show me a circumstance where sin(x - 2 * pi) and sin(x

Re: Sine and Cosine Accuracy

Georg Bauhaus <[EMAIL PROTECTED]> writes: | Bernhard R. Link wrote: | | > naming any range smaller than some [-50pi,100pi] "valid" could | > really make me crazy... | | No one is asking for sine to be restricted in this way. Howwever, someone came in lectureing us on: Yes, but within the de

Re: Sine and Cosine Accuracy

Bernhard R. Link wrote: naming any range smaller than some [-50pi,100pi] "valid" could really make me crazy... No one is asking for sine to be restricted in this way. Some are asking for the freedom to request this or that kind of sine computation to be generated, because they know that for *t

Re: Sine and Cosine Accuracy

* Georg Bauhaus <[EMAIL PROTECTED]> [050530 19:34]: > Programmers write calls to functions named "sin" and "cos" for > reaons of getting a result that is near what the mathematical > model (involving the same names sin and cos) would suggest. > Question is, how and when should GCC enable a programm

Re: Sine and Cosine Accuracy

Bernhard R. Link wrote: Sorry, but sin and cos are mathematical functions. The mathematical functions sin and cos are mathematical functions in mathematics but almost never in GCC's world, "almost never" in the mathematical sense: They can almost never be computed by programs translated using

Re: Sine and Cosine Accuracy

Bernhard R. Link wrote: > Breaking things like sin(-x) or sin(x+y) will definitly hurt people, > because it is natural to expect this to work. Where in the name of [insert diety here] did I *ever* say I wanted to break anything? Just because something breaks *your* application doesn't mean I shou

Re: Sine and Cosine Accuracy

Marc Espie wrote: > Funny, I don't expect any message from that signature. > > Gabriel dos Reis, on the other hand, may have something to say... A regrettable mistake, brought on by spending too many years in Spanish-speaking areas, where "rio" is river. ..Scott

Re: Sine and Cosine Accuracy

Marc Espie wrote: > Heck, I can plot trajectories on a sphere that do not follow great circles, > and that extend over 360 degrees in longitude. I don't see why I should be > restricted from doing that. Can you show me a circumstance where sin(x - 2 * pi) and sin(x + 2 * pi) are not equal to sin(

Re: Sine and Cosine Accuracy

Marc Espie wrote: > Heck, I can plot trajectories on a sphere that do not follow great circles, > and that extend over 360 degrees in longitude. I don't see why I should be > restricted from doing that. Can you show me a circumstance where sin(x - 2 * pi) and sin(x + 2 * pi) are not equal to sin(

Re: Sine and Cosine Accuracy

On Sun, May 29, 2005 at 05:52:11PM -0400, Scott Robert Ladd wrote: > (I expect Gabriel dos Rios to respond with something pithy here; please > don't disappoint me!) Funny, I don't expect any message from that signature. Gabriel dos Reis, on the other hand, may have something to say...

Re: Sine and Cosine Accuracy

* Georg Bauhaus <[EMAIL PROTECTED]> [050529 20:53]: > By "real circle" I mean a thing that is not obfuscated by the useful > but strange ways in which things are redefined by mathematicians; > cf. Halmos for some humor. Sorry, but sin and cos are mathematical functions. If you want to invent some

Re: Sine and Cosine Accuracy

On 2005-05-29 01:33:43 -0600, Roger Sayle wrote: > I apologise for coming into this argument late. I'll admit that I > haven't even caught up on the entire thread, but an interesting > relevant article that may or may not have already been mentioned is: > > http://web.archive.org/web/200404091447

Re: Sine and Cosine Accuracy

On Sun, May 29, 2005 at 08:59:00PM +0200, Georg Bauhaus wrote: > Marc Espie wrote: > >Sorry for chiming in after all this time, but I can't let this pass. > > > >Scott, where on earth did you pick up your trig books ? > > Sorry, too, but why one earth do modern time mathematics scholars > think th

Re: Sine and Cosine Accuracy

Georg Bauhaus <[EMAIL PROTECTED]> writes: | Marc Espie wrote: | > Sorry for chiming in after all this time, but I can't let this pass. | > Scott, where on earth did you pick up your trig books ? | | Sorry, too, but why one earth do modern time mathematics scholars | think that sine and cosine are

Re: Sine and Cosine Accuracy

Marc Espie wrote: Sorry for chiming in after all this time, but I can't let this pass. Scott, where on earth did you pick up your trig books ? Sorry, too, but why one earth do modern time mathematics scholars think that sine and cosine are bound to have to do with an equally modern notion of r

Re: Sine and Cosine Accuracy

Sorry for chiming in after all this time, but I can't let this pass. Scott, where on earth did you pick up your trig books ? The mathematical functions sine and cosine are defined everywhere. There is absolutely 0 identity involving them which doesn't apply all over the real, or the complex plane

Re: Sine and Cosine Accuracy

On Thu, 26 May 2005, Scott Robert Ladd wrote: > I prefer breaking out the hardware intrinsics from > -funsafe-math-optimizations, such that people can compile to use their > hardware *without* the other transformations implicit in the current > collective. > > If someone can explain how this hurts

Re: Sine and Cosine Accuracy

Paul Koning <[EMAIL PROTECTED]> writes: > After some off-line exchanges with Dave Korn, it seems to me that part > of the problem is that the documentation for > -funsafe-math-optimizations is so vague as to have no discernable > meaning. > > For example, does the wording of the documentation co

Re: Sine and Cosine Accuracy

[EMAIL PROTECTED] (Richard Henderson) wrote on 26.05.05 in <[EMAIL PROTECTED]>: > On Thu, May 26, 2005 at 10:34:14AM -0400, Scott Robert Ladd wrote: > > static const double range = PI; // * 2.0; > > static const double incr = PI / 100.0; > > The trig insns fail with large numbers; an arg

Re: Sine and Cosine Accuracy

[EMAIL PROTECTED] (Scott Robert Ladd) wrote on 26.05.05 in <[EMAIL PROTECTED]>: > Paul Koning wrote: > > Scott> Yes, but within the defined mathematical ranges for sine and > > Scott> cosine -- [0, 2 * PI) -- the processor intrinsics are quite > > Scott> accurate. > I *said* that such stateme

Re: Sine and Cosine Accuracy

Scott Robert Ladd <[EMAIL PROTECTED]> writes: > Gabriel Dos Reis wrote: >> Scott Robert Ladd <[EMAIL PROTECTED]> writes: >> | Then, as someone else said, why doesn't the compiler enforce -ansi >> | and/or -pedantic by default? >> Care submitting a ptach? > Would a strictly ansi default be accept

RE: Sine and Cosine Accuracy

> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of > Menezes, Evandro > Sent: Friday, May 27, 2005 1:55 PM [...] > > That's because the error is the same but symmetrical for sin and > cos, so that, when you calculate the sum of their squares, one > cance

RE: Sine and Cosine Accuracy

Scott, > I still maintain that hardware fsin and fcos are valid and > valuable for certain classes of applications, I agree. I've just been trying to demonstrate that your test doesn't check sin and cos accuracies, but that sin^2 + cos^2 == 1. If I had a sin that always returned 1.0 and a c

Re: Sine and Cosine Accuracy

Evandro, > Any perceived increase in accuracy in this test comes > from intermediary calculations being done with 80 bits and > because the errors in fsin are complementary to those in fcos. I'm always willing to see my mistakes revealed, if it can be done so eloquently and politely. Unlike some

RE: Sine and Cosine Accuracy

Scott, > Actually, it tested every 1.8°, but who wants to be picky. > I've rerun the test overnight at greater resolution, testing every > 0.0018 degress, and saw no change in the result. That's because the error is the same but symmetrical for sin and cos, so that, when you calculate the

Re: Sine and Cosine Accuracy

On 2005-05-27, at 15:36, Olivier Galibert wrote: Floating point values represent intervals, This is mathematically wrong. The basic concept is that the calculations domain as given by floating point numbers is used to *model* the real number calculus. Certain constrains apply of course. But th

Re: Sine and Cosine Accuracy

On 2005-05-27 15:36:51 +0200, Olivier Galibert wrote: > If you're evaluating it at the floating point value 2^90 you're just > evaluating a fancy prng. Floating point values represent intervals, They don't. Have you never heard of correlation? -- Vincent Lefèvre <[EMAIL PROTECTED]> - Web:

Re: Sine and Cosine Accuracy

On 2005-05-26 16:33:00 -0500, Menezes, Evandro wrote: > Keep in mind that x87 transcendentals are not the most accurate > around, but all x86 processors from any manufacturer produce roughly > the same results for any argument as the 8087 did way back when, > even if the result is hundreds of ulps

Re: Sine and Cosine Accuracy

On Fri, May 27, 2005 at 12:26:13AM +0200, Gabriel Dos Reis wrote: > If it was and angle! Not everything that is an argument to sin or cos > is an angle. They are just functions! Suppose you're evaluating an > approximation of a Fourrier series expansion. If you're evaluating it at the floating

Re: Sine and Cosine Accuracy

On 2005-05-26 12:04:04 -0400, Scott Robert Ladd wrote: > I've never quite understood the necessity for performing trig > operations on excessively large values, but perhaps my problem > domain hasn't included such applications. This can happen in some numerical applications (the same expressions a

Re: Sine and Cosine Accuracy

Menezes, Evandro wrote: > Your code just tests every 3.6°, perhaps you won't trip at the > problems... Actually, it tested every 1.8°, but who wants to be picky. I've rerun the test overnight at greater resolution, testing every 0.0018 degress, and saw no change in the result. ..Scott

Re: Sine and Cosine Accuracy

On 2005-05-26, at 22:39, Gabriel Dos Reis wrote: Scott Robert Ladd <[EMAIL PROTECTED]> writes: | Richard Henderson wrote: | > On Thu, May 26, 2005 at 10:34:14AM -0400, Scott Robert Ladd wrote: | > | >>static const double range = PI; // * 2.0; | >>static const double incr = PI / 100.0;

Re: Sine and Cosine Accuracy

On 2005-05-27, at 00:00, Gabriel Dos Reis wrote: Yeah, the problem with people who work only with angles is that they tend to forget that sin (and friends) are defined as functions on *numbers*, The problem with people who work only with angles is that they are without sin.

Re: Sine and Cosine Accuracy

On 2005-05-26, at 21:34, Scott Robert Ladd wrote: For many practical problems, the world can be considered flat. And I do plenty of spherical geometry (GPS navigation) without requiring the sin of 2**90. ;) Yes right. I guess your second name is ignorance.

Re: Sine and Cosine Accuracy

Menezes, Evandro wrote: > Besides, you're also comparing 80-bit calculations with 64-bit > calculations, not only the accuracy of sin and cos. Try using > -ffloat-store along with -mfpmath=387 and see yet another set of > results. At the end of the day, which one do you trust? I wouldn't > trust

Re: Sine and Cosine Accuracy

Gabriel Dos Reis wrote: > Scott Robert Ladd <[EMAIL PROTECTED]> writes: > | Then, as someone else said, why doesn't the compiler enforce -ansi > | and/or -pedantic by default? > > Care submitting a ptach? Would a strictly ansi default be accepted on principle? Given the existing code base of non-

RE: Sine and Cosine Accuracy

Scott, > > This is not true. Compare results on an x86 systems with > those on an > > x86_64 or ppc. As I said before, shortcuts were taken in x87 that > > sacrificed accuracy for the sake of speed initially and later of > > compatibility. > > It *is* true for the case where the argument is

Re: Sine and Cosine Accuracy

Menezes, Evandro wrote: > This is not true. Compare results on an x86 systems with those on an > x86_64 or ppc. As I said before, shortcuts were taken in x87 that > sacrificed accuracy for the sake of speed initially and later of > compatibility. It *is* true for the case where the argument is i

Re: Sine and Cosine Accuracy

Scott Robert Ladd <[EMAIL PROTECTED]> writes: | Gabriel Dos Reis wrote: | > Yeah, the problem with people who work only with angles is that they | > tend to forget that sin (and friends) are defined as functions on | > *numbers*, not just angles or whatever, and happen to appear in | > approximati

Re: Sine and Cosine Accuracy

Scott Robert Ladd <[EMAIL PROTECTED]> writes: | Richard Henderson wrote: | > On Thu, May 26, 2005 at 12:04:04PM -0400, Scott Robert Ladd wrote: | > | >>I've never quite understood the necessity for performing trig operations | >>on excessively large values, but perhaps my problem domain hasn't |

RE: Sine and Cosine Accuracy

Scott, > For a wide variety of applications, the hardware intrinsics > provide both faster and more accurate results, when compared > to the library functions. This is not true. Compare results on an x86 systems with those on an x86_64 or ppc. As I said before, shortcuts were taken in x87 t

Re: Sine and Cosine Accuracy

Gabriel Dos Reis wrote: > Yeah, the problem with people who work only with angles is that they > tend to forget that sin (and friends) are defined as functions on > *numbers*, not just angles or whatever, and happen to appear in > approximations of functions as series (e.g. Fourier series) and ther

Re: Sine and Cosine Accuracy

Richard Henderson wrote: > On Thu, May 26, 2005 at 12:04:04PM -0400, Scott Robert Ladd wrote: > >>I've never quite understood the necessity for performing trig operations >>on excessively large values, but perhaps my problem domain hasn't >>included such applications. > > > Whether you think it

RE: Sine and Cosine Accuracy

Uros, > However, the argument to fsin can be reduced to an > acceptable range by using fmod builtin. Internally, this > builtin is implemented as a very tight loop that check for > insufficient reduction, and could reduce whatever finite > value one wishes. Keep in mind that x87 transcende

Re: Sine and Cosine Accuracy

On Friday 27 May 2005 00:26, Gabriel Dos Reis wrote: > Uros Bizjak <[EMAIL PROTECTED]> writes: > > [...] > > | Out of curiosity, where could sin(2^90) be needed? It looks rather > | big angle to me. > > If it was and angle! Not everything that is an argument to sin or cos > is an angle. They ar

Re: Sine and Cosine Accuracy

Uros Bizjak <[EMAIL PROTECTED]> writes: [...] | Out of curiosity, where could sin(2^90) be needed? It looks rather | big angle to me. If it was and angle! Not everything that is an argument to sin or cos is an angle. They are just functions! Suppose you're evaluating an approximation of a F

Re: Sine and Cosine Accuracy

> "Uros" == Uros Bizjak <[EMAIL PROTECTED]> writes: Uros> Hello! >> Fair enough, so with 64 bit floats you have no right to expect an >> accurate answer for sin(2^90). However, you DO have a right to >> expect an answer in the range [-1,+1] rather than the 1.2e+27 that >> Richard quoted.

Re: Sine and Cosine Accuracy

Hello! Fair enough, so with 64 bit floats you have no right to expect an accurate answer for sin(2^90). However, you DO have a right to expect an answer in the range [-1,+1] rather than the 1.2e+27 that Richard quoted. I see no words in the description of -funsafe-math-optimizations to lead me

Re: Sine and Cosine Accuracy

Scott Robert Ladd <[EMAIL PROTECTED]> writes: | Gabriel Dos Reis wrote: | > Scott Robert Ladd <[EMAIL PROTECTED]> writes: | > | I've never quite understood the necessity for performing trig operations | > | on excessively large values, but perhaps my problem domain hasn't | > | included such appli

Re: Sine and Cosine Accuracy

On Thu, May 26, 2005 at 12:04:04PM -0400, Scott Robert Ladd wrote: > I've never quite understood the necessity for performing trig operations > on excessively large values, but perhaps my problem domain hasn't > included such applications. Whether you think it necessary or not, the ISO C functions

Re: Sine and Cosine Accuracy

Gabriel Dos Reis wrote: > Scott Robert Ladd <[EMAIL PROTECTED]> writes: > | I've never quite understood the necessity for performing trig operations > | on excessively large values, but perhaps my problem domain hasn't > | included such applications. > > The world is flat; I never quite understood

Re: Sine and Cosine Accuracy

Scott Robert Ladd <[EMAIL PROTECTED]> writes: | Richard Henderson wrote: | > On Thu, May 26, 2005 at 10:34:14AM -0400, Scott Robert Ladd wrote: | > | >>static const double range = PI; // * 2.0; | >>static const double incr = PI / 100.0; | > | > | > The trig insns fail with large number

Re: Sine and Cosine Accuracy

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 fo

Re: Sine and Cosine Accuracy

On Thu, 26 May 2005, Paul Koning wrote: > > "Kevin" == Kevin Handy <[EMAIL PROTECTED]> writes: > > Kevin> But, you are using a number in the range of 2^90, only have 64 > Kevin> bits for storing the floating point representation, and some > Kevin> of that is needed for the exponent. > > F

Re: Sine and Cosine Accuracy

Andrew Pinski wrote: > b) means that (-a)*(b-c) can be changed to a*(c-b) and other reassociation > opportunities. This is precisely the sort of transformation that, in my opinion, should be separate from the hardware intrinsics. I mentioned this specific case earlier in the thread (I think; maybe

RE: Sine and Cosine Accuracy

Original Message >From: Scott Robert Ladd >Sent: 26 May 2005 19:09 > Dave Korn wrote: >> Well, as long as they're under the control of a flag that also makes it >> clear that they are *also* unsafe math optimisations, I wouldn't object. > > But they are *not* unsafe for *all* applicatio

Re: Sine and Cosine Accuracy

On May 26, 2005, at 2:12 PM, Paul Koning wrote: What does (b) mean? What if anything are its limitations? Is returning 1.2e27 as the result for a sin() call authorized by (b)? I would not have expected that, but I can't defend that expectation based on a literal reading of the text... b) m

Re: Sine and Cosine Accuracy

After some off-line exchanges with Dave Korn, it seems to me that part of the problem is that the documentation for -funsafe-math-optimizations is so vague as to have no discernable meaning. For example, does the wording of the documentation convey the limitation that one should only invoke math

Re: Sine and Cosine Accuracy

Dave Korn wrote: > Well, as long as they're under the control of a flag that also makes it > clear that they are *also* unsafe math optimisations, I wouldn't object. But they are *not* unsafe for *all* applications. An ignorant user may not understand the ramifications of "unsafe" math -- howev

Re: Sine and Cosine Accuracy

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

Re: Sine and Cosine Accuracy

Paul Koning wrote: > I'm really puzzled by that comment, partly because the text book quote > you gave doesn't match any math I ever learned. Does "knowing your > math" translates to "believing that trig functions should be applied > only to arguments in the range 0 to 2pi"? If so, I must object.

RE: Sine and Cosine Accuracy

Original Message >From: Scott Robert Ladd >Sent: 26 May 2005 18:36 > I am simply lobbying for the separation of hardware intrinsics from > -funsafe-math-optimizations. Well, as long as they're under the control of a flag that also makes it clear that they are *also* unsafe math optimi

Re: Sine and Cosine Accuracy

> "Scott" == Scott Robert Ladd <[EMAIL PROTECTED]> writes: Scott> Dave Korn wrote: >> It's difficult to tell from that quote, which lacks sufficient >> context, but you *appear* at first glance to be conflating the >> fundamental trignometric *functions* with the trignometric >> *identiti

Re: Sine and Cosine Accuracy

Morten Welinder wrote: > If you were to look up a serious math book like Abramowitz&Stegun1965 > you would see a definition like > > sin z = ((exp(iz)-exp(-iz))/2i [4.3.1] Very true. However, the processor doesn't implement intrinsics for complex functions -- well, maybe som

RE: Sine and Cosine Accuracy

Original Message >From: David Daney >Sent: 26 May 2005 18:23 > Dave Korn wrote: > >> " Identities such as >> sin(x)^2 + cos(x)^2 === 1 >> are only valid when 0 <= x <= 2*PI" >> > > It's been a while since I studied math, but isn't that particular > identity is true for any

Re: Sine and Cosine Accuracy

> Yes, but within the defined mathematical ranges for sine and cosine -- > [0, 2 * PI) -- the processor intrinsics are quite accurate. If you were to look up a serious math book like Abramowitz&Stegun1965 you would see a definition like sin z = ((exp(iz)-exp(-iz))/2i [4.3.1]

Re: Sine and Cosine Accuracy

> "Kevin" == Kevin Handy <[EMAIL PROTECTED]> writes: Kevin> But, you are using a number in the range of 2^90, only have 64 Kevin> bits for storing the floating point representation, and some Kevin> of that is needed for the exponent. Fair enough, so with 64 bit floats you have no right to

Re: Sine and Cosine Accuracy

Dave Korn wrote: > It's difficult to tell from that quote, which lacks sufficient context, > but you *appear* at first glance to be conflating the fundamental > trignometric *functions* with the trignometric *identities* that are > generally built up from those functions. That is to say, you ap

Re: Sine and Cosine Accuracy

Dave Korn wrote: " Identities such as sin(x)^2 + cos(x)^2 === 1 are only valid when 0 <= x <= 2*PI" It's been a while since I studied math, but isn't that particular identity is true for any x real or complex? David Daney,

Re: Sine and Cosine Accuracy

Paul Koning wrote: "Scott" == Scott Robert Ladd <[EMAIL PROTECTED]> writes: Scott> Richard Henderson wrote: >> On Thu, May 26, 2005 at 10:34:14AM -0400, Scott Robert Ladd wrote: >> >>> static const double range = PI; // * 2.0; static const double >>> incr = PI / 100.0; >> >> >

RE: Sine and Cosine Accuracy

Original Message >From: Scott Robert Ladd >Sent: 26 May 2005 17:32 > Paul Koning wrote: >> Scott> Yes, but within the defined mathematical ranges for sine and >> Scott> cosine -- [0, 2 * PI) -- the processor intrinsics are quite >> Scott> accurate. >> >> Huh? Sine and consine are mat

Re: Sine and Cosine Accuracy

Paul Koning wrote: > Scott> Yes, but within the defined mathematical ranges for sine and > Scott> cosine -- [0, 2 * PI) -- the processor intrinsics are quite > Scott> accurate. > > Huh? Sine and consine are mathematically defined for all finite > inputs. Defined, yes. However, I'm speaking a

Re: Sine and Cosine Accuracy

> "Scott" == Scott Robert Ladd <[EMAIL PROTECTED]> writes: Scott> Richard Henderson wrote: >> On Thu, May 26, 2005 at 10:34:14AM -0400, Scott Robert Ladd wrote: >> >>> static const double range = PI; // * 2.0; static const double >>> incr = PI / 100.0; >> >> >> The trig insns fail w

Re: Sine and Cosine Accuracy

Richard Henderson wrote: > On Thu, May 26, 2005 at 10:34:14AM -0400, Scott Robert Ladd wrote: > >>static const double range = PI; // * 2.0; >>static const double incr = PI / 100.0; > > > The trig insns fail with large numbers; an argument > reduction loop is required with their use. Ye

Re: Sine and Cosine Accuracy

On Thu, May 26, 2005 at 10:34:14AM -0400, Scott Robert Ladd wrote: > static const double range = PI; // * 2.0; > static const double incr = PI / 100.0; The trig insns fail with large numbers; an argument reduction loop is required with their use. r~

Re: Sine and Cosine Accuracy

Scott Robert Ladd writes: > Andrew Haley wrote: > > Try this: > > > > public class trial > > { > > static public void main (String[] argv) > > { > > System.out.println(Math.sin(Math.pow(2.0, 90.0))); > > } > > } > > > > zapata:~ $ gcj trial.java --main=trial -ffast-math -O

Re: Sine and Cosine Accuracy

Andrew Haley wrote > zapata:~ $ gcj trial.java --main=trial -ffast-math -O ^^ Ok, maybe those people that are accusing the Free Software philosophy of being akin to communisn are wrong, but it looks like revolutionaries are lurking around, at least... ;) ;) Paolo.

Re: Sine and Cosine Accuracy

Andrew Haley wrote: > Try this: > > public class trial > { > static public void main (String[] argv) > { > System.out.println(Math.sin(Math.pow(2.0, 90.0))); > } > } > > zapata:~ $ gcj trial.java --main=trial -ffast-math -O > zapata:~ $ ./a.out > 1.2379400392853803E27 > zapata:~ $ gcj

Re: Sine and Cosine Accuracy

Scott Robert Ladd writes: > > The program used is below. I'm very open to suggestions about this > program, which is a subset of a larger accuracy benchmark I'm writing > (Subtilis). Try this: public class trial { static public void main (String[] argv) { System.out.println(Math.sin(