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)
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 subtracting
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] (or
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 discernable
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
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:
* 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
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...
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
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
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
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
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
* 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 programmer to
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
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
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
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
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 that sine
[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 statements are
[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 argument
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 convey
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
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
are
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
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:
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
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
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
-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
cancels the
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)
{
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 trial.java
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.
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
zapata:~ $ ./a.out
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.
Yes, but
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 with large numbers; an
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 as a
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 mathematically
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,
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
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 expect an
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 AbramowitzStegun1965
you would see a definition like
sin z = ((exp(iz)-exp(-iz))/2i [4.3.1]
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 x real or
Morten Welinder wrote:
If you were to look up a serious math book like AbramowitzStegun1965
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 some
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
*identities* that are
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
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.
I'll
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
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)
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* applications.
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
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.
Fair enough, so
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 numbers; an
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 the
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
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
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
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. I see no words
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
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 are just
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
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 necessary
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
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
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
|
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
| approximations
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 in
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 in the
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
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 my
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.
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.
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;
|
|
73 matches
Mail list logo
