Hello
I downloaded glibc and tried looking for the code that implements the
sine function
i couldnt find the file.
i went to the math directory and found math.h.. i guess that needs to be
included for the sine function. but which .c file implements the
sine/cosine and other trig fns
thanks
Nov 14 '05
143 8123
"Dan Pop" <Da*****@cern.c h> wrote in message
news:c8******** **@sunnews.cern .ch... In <V2************ ********@nwrddc 02.gnilink.net> "P.J. Plauger"
<pj*@dinkumware .com> writes:"Dan Pop" <Da*****@cern.c h> wrote in message news:c8******* ****@sunnews.ce rn.ch...
In <40************ ***@yahoo.com> CBFalconer <cb********@yah oo.com>
writes: >Dan Pop wrote: >> >... snip ... >> >> The point is not whether it can be calculated, but rather how much >> precision should the calculation produce? Does it makes sense to >> compute sin(DBL_MAX) with 53-bit precision, ignoring the fact that >> DBL_MAX stands for an interval so large as to make this function >> call completely devoid of any meaning? > >PJPs point is that that interval is the range of values specified, >with the actual value being the most likely value in the range. >The shape of the probability curve in the interval is known only >to the end user. It may be an impulse function precisely at the >specified value.
Or it may not. If I deserve 5 digits of precision, why should the implementation waste precious CPU resources to give me 16 digits of *bogus* precision?
Because it doesn't know that it shouldn't? You could supply a useful hint by calling sinf, in this particular case at least.
sinf is useless in portable C code.
But wait a minute. You've just outlined a "concrete example" where
you know you deserve only 5 digits of precision. sinf will meet
your needs *portably*. And it won't waste your precious CPU resources
to give you 16 digits of *bogus* precison. How can you call that
useless when you just outlined a concrete use case where it portably
meets your needs exactly? To deserve 16 digits of precision, it is *my* job to call sin() with an argument of the right magnitude. It's as simple as that.
Simple for you, perhaps, but the interface for sin currently fails to provide any information about how many of the bits you're supplying should be taken seriously.
ALL of them, as I have already explained you. It's the magnitude of the value that decides how many digits of precision I deserve in the result.
But you've yet to commit to any *concrete* rule for deciding how many
digits you deserve given the magnitude of the argument value. And you
say we're at fault if a library takes more time than it should. We're
looking to you for guidance in this area, particularly since you seem
to have such a clear vision of the right way to do things. Please provide
wording for a correction to the C Standard so we can all critique it and
then adopt it. We're counting on you for leadership.
P.J. Plauger
Dinkumware, Ltd. http://www.dinkumware.com
In <Hx********@cwi .nl> "Dik T. Winter" <Di********@cwi .nl> writes: In article <c8***********@ sunnews.cern.ch > Da*****@cern.ch (Dan Pop) writes: In <Hx********@cwi .nl> "Dik T. Winter" <Di********@cwi .nl> writes: ... > I would certainly look carefully at them, especially > if done with matrix inversion.
Also with Gauss' elimination. If you really think that the input numbers are intervals, in almost all cases the result makes no sense.
Unless the input numbers can be exactly represented in floating point, it is sheer foolishness to consider them as exact values. Furthermore, in real life applications, most input numbers are obtained with a precision even lower than that provided by the floating point representation, so they stand for even larger intervals. That's why the results are intervals, too. Consider the difference between 1 +/- 1000 and 1 +/- 0.001. Only a patent fool will display the result as a plain 1 in both cases.
Ah, so, what method do *you* use to solve linear systems on the computer?
I don't solve linear systems on the computer. Yet, as far as I know, all
the usual methods come bundled with an error analysis, that allows
computing the precision of the results. If you don't compute this
precision, what's the point in solving the linear systems in the first
place? There are more efficient random number generators...
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
In <EJ************ **@nwrddc03.gni link.net> "P.J. Plauger" <pj*@dinkumware .com> writes: "Dan Pop" <Da*****@cern.c h> wrote in message news:c8******* ***@sunnews.cer n.ch...
In <V2************ ********@nwrddc 02.gnilink.net> "P.J. Plauger" <pj*@dinkumwar e.com> writes: >"Dan Pop" <Da*****@cern.c h> wrote in message >news:c8******* ****@sunnews.ce rn.ch... > >> In <40************ ***@yahoo.com> CBFalconer <cb********@yah oo.com>writes: >> >> >Dan Pop wrote: >> >> >> >... snip ... >> >> >> >> The point is not whether it can be calculated, but rather how much >> >> precision should the calculation produce? Does it makes sense to >> >> compute sin(DBL_MAX) with 53-bit precision, ignoring the fact that >> >> DBL_MAX stands for an interval so large as to make this function >> >> call completely devoid of any meaning? >> > >> >PJPs point is that that interval is the range of values specified, >> >with the actual value being the most likely value in the range. >> >The shape of the probability curve in the interval is known only >> >to the end user. It may be an impulse function precisely at the >> >specified value. >> >> Or it may not. If I deserve 5 digits of precision, why should the >> implementation waste precious CPU resources to give me 16 digits of >> *bogus* precision? > >Because it doesn't know that it shouldn't? You could supply a useful >hint by calling sinf, in this particular case at least.
sinf is useless in portable C code.
But wait a minute. You've just outlined a "concrete example" where you know you deserve only 5 digits of precision. sinf will meet your needs *portably*. And it won't waste your precious CPU resources to give you 16 digits of *bogus* precison. How can you call that useless when you just outlined a concrete use case where it portably meets your needs exactly?
sinf is a C99 invention and the portability of C99 code is extremely
impaired by the number of implementations claiming C99-conformance.
C99 is perfectly futile to anyone concerned about the portability of his
code. At best, it's a guide about what C89 user space identifiers not
to use in your code (because C99 has no qualms stomping on the C89 user
name space). >> To deserve 16 digits of precision, it is *my* job to call sin() with >> an argument of the right magnitude. It's as simple as that. > >Simple for you, perhaps, but the interface for sin currently fails >to provide any information about how many of the bits you're supplying >should be taken seriously.
ALL of them, as I have already explained you. It's the magnitude of the value that decides how many digits of precision I deserve in the result.
But you've yet to commit to any *concrete* rule for deciding how many digits you deserve given the magnitude of the argument value.
I have already provided the rule, last week. And when I asked if it was
concrete enough for you, you didn't object.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
"Dan Pop" <Da*****@cern.c h> wrote in message
news:c8******** **@sunnews.cern .ch... sinf is useless in portable C code. But wait a minute. You've just outlined a "concrete example" where you know you deserve only 5 digits of precision. sinf will meet your needs *portably*. And it won't waste your precious CPU resources to give you 16 digits of *bogus* precison. How can you call that useless when you just outlined a concrete use case where it portably meets your needs exactly?
sinf is a C99 invention and the portability of C99 code is extremely impaired by the number of implementations claiming C99-conformance.
Actually it's described in C89.
C99 is perfectly futile to anyone concerned about the portability of his code. At best, it's a guide about what C89 user space identifiers not to use in your code (because C99 has no qualms stomping on the C89 user name space).
sinf has been reserved since 1989, so I can't imagine how using it
could possibly "stomp on" any program. But that's okay, I understand
that you're trolling. >> To deserve 16 digits of precision, it is *my* job to call sin() with >> an argument of the right magnitude. It's as simple as that. > >Simple for you, perhaps, but the interface for sin currently fails >to provide any information about how many of the bits you're supplying >should be taken seriously.
ALL of them, as I have already explained you. It's the magnitude of
the value that decides how many digits of precision I deserve in the
result. But you've yet to commit to any *concrete* rule for deciding how many digits you deserve given the magnitude of the argument value.
I have already provided the rule, last week. And when I asked if it was concrete enough for you, you didn't object.
Oh sorry, I thought you were explaining your (mis)understand ing
of the problem with this interaction:
: > >So all the sine function needs is an indication of how much fuzz to
: > >assume in the argument. I've yet to hear a specific criterion. Concrete
: > >example please.
: >
: > Assume all the bits of the argument are exact and the *only* source
: > of fuziness is the magnitude of the value. By the time the least
: > significant bit of the mantissa means more than 2 * pi, the fuziness
: > is complete (any result in the -1..1 range is correct).
: >
: > Is that concrete enough for you?
:
: Yes, it's concrete enough to show that you still don't get it.
So what you're committing to is the requirement that the sine
should *not* be computed for any value where 1 ulp weighs more
than 2*pi. And presumably, sine should deliver the best possible
approximation to any argument less than this magnitude. (This
is fine with me, since it still requires an argument reduction
using about 2 1/2 words of precision, so it will break the
vast majority of sine functions that have been in use for the
past several decades. But hey, we're covered, so I'm happy.)
Of course, you still need to specify what to return for the
garbage value, and what error to report (if any). I await your
further guidance.
So you're willing to stand behind this criterion even after I
described, in a later posting, the various ways in which it was
arbitrary? If this is submitted as a DR to WG14, you're
willing, as it's original author and proposer, to defend it
against cranky attacks by people who haven't thought through
the matter as carefully as you?
Brave of you. We can call it the Pop Criterion.
P.J. Plauger
Dinkumware, Ltd. http://www.dinkumware.com
In article <c8**********@s unnews.cern.ch> , Da*****@cern.ch (Dan Pop)
wrote: I don't solve linear systems on the computer. Yet, as far as I know, all the usual methods come bundled with an error analysis, that allows computing the precision of the results. If you don't compute this precision, what's the point in solving the linear systems in the first place? There are more efficient random number generators...
It depends. Do you want a set of numbers that is close to the correct
solution of the systems, or do you want a set of numbers that is very
close to being a solution, that is each equation is solved with a small
error?
For many systems, you can get the second much easier than the first. Or
lets say you want to minimise f (x). It often doesn't matter whether you
find an x' that is close to the x with the smallest value or not, but
what you want is an x' such that f (x') is close to the smallest value
of f (x).
In article <ch************ *************** ******@slb-newsm1.svr.pol. co.uk> Christian Bau <ch***********@ cbau.freeserve. co.uk> writes: In article <c8**********@s unnews.cern.ch> , Da*****@cern.ch (Dan Pop) wrote: I don't solve linear systems on the computer. Yet, as far as I know, all the usual methods come bundled with an error analysis, that allows computing the precision of the results. If you don't compute this precision, what's the point in solving the linear systems in the first place? There are more efficient random number generators...
It depends. Do you want a set of numbers that is close to the correct solution of the systems, or do you want a set of numbers that is very close to being a solution, that is each equation is solved with a small error?
The actual methods most commonly used give the exact solution to a system
that differs from the original system with a small error. This does *not*
mean that the solution is close to the exact solution of the exact original
problem. It is close to it when the condition number of the original
matrix is good. And that is what the error analysis does do (backward
error analysis as introduced by J.H. Wilkinson).
To compute the precision of the result you have to do much more than is
feasable in most cases. Have a look at Karlsruhe arithmetic from the
University at Karlsruhe.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
In <Hx********@cwi .nl> "Dik T. Winter" <Di********@cwi .nl> writes: To compute the precision of the result you have to do much more than is feasable in most cases.
What is the value of a result with unknown precision? To repeat my
earlier example, if you don't know if it's 1 +/- 0.001 or 1 +/- 1000,
the value of 1 is of pretty little use.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
In <9L************ ****@nwrddc03.g nilink.net> "P.J. Plauger" <pj*@dinkumware .com> writes: "Dan Pop" <Da*****@cern.c h> wrote in message news:c8******* ***@sunnews.cer n.ch...
>> sinf is useless in portable C code. > >But wait a minute. You've just outlined a "concrete example" where >you know you deserve only 5 digits of precision. sinf will meet >your needs *portably*. And it won't waste your precious CPU resources >to give you 16 digits of *bogus* precison. How can you call that >useless when you just outlined a concrete use case where it portably >meets your needs exactly? sinf is a C99 invention and the portability of C99 code is extremely impaired by the number of implementations claiming C99-conformance.
Actually it's described in C89.
Are you trolling? It may be described in C89 (as a reserved identifier)
but no conforming C89 implementation is required to provide it. Your
own published implementation of the standard C89 library doesn't... C99 is perfectly futile to anyone concerned about the portability of his code. At best, it's a guide about what C89 user space identifiers not to use in your code (because C99 has no qualms stomping on the C89 user name space).
sinf has been reserved since 1989, so I can't imagine how using it could possibly "stomp on" any program. But that's okay, I understand that you're trolling.
You're trolling. I was talking in general terms: there are dozens of C99
standard library functions whose names belong to the C89 user name space:
all of <complex.h> and <fenv.h>, as well as additions to other headers,
including something as innocuous as round(). >> >> To deserve 16 digits of precision, it is *my* job to call sin() with >> >> an argument of the right magnitude. It's as simple as that. >> > >> >Simple for you, perhaps, but the interface for sin currently fails >> >to provide any information about how many of the bits you're supplying >> >should be taken seriously. >> >> ALL of them, as I have already explained you. It's the magnitude ofthe >> value that decides how many digits of precision I deserve in theresult. > >But you've yet to commit to any *concrete* rule for deciding how many >digits you deserve given the magnitude of the argument value.
I have already provided the rule, last week. And when I asked if it was concrete enough for you, you didn't object.
Oh sorry, I thought you were explaining your (mis)understand ing of the problem with this interaction:
: > >So all the sine function needs is an indication of how much fuzz to : > >assume in the argument. I've yet to hear a specific criterion. Concrete : > >example please. : > : > Assume all the bits of the argument are exact and the *only* source : > of fuziness is the magnitude of the value. By the time the least : > significant bit of the mantissa means more than 2 * pi, the fuziness : > is complete (any result in the -1..1 range is correct). : > : > Is that concrete enough for you? : : Yes, it's concrete enough to show that you still don't get it.
So what you're committing to is the requirement that the sine should *not* be computed for any value where 1 ulp weighs more than 2*pi.
That's too strong. I would still expect
sin(DBL_MAX) * sin(DBL_MAX) + cos(DBL_MAX) * cos(DBL_MAX)
to be reasonably close to 1.0, if not equal to it. But, other than that,
any value in the [-1, 1] range is OK once 1 ulp exceeds 2*pi.
And presumably, sine should deliver the best possible approximatio n to any argument less than this magnitude.
Not even that. If the value in question covers the range [min, max],
sine should provide the best possible approximation of sin(x), where x
is one value in the range [min, max].
(This is fine with me, since it still requires an argument reduction using about 2 1/2 words of precision, so it will break the vast majority of sine functions that have been in use for the past several decades.
Only the ones that have been *misused*. If I measure the volume of a
sphere with a precision of 1 cubical centimeter, does it make any sense
to compute *and display* its radius with picometer precision?
But hey, we're covered, so I'm happy.) Of course, you still need to specify what to return for the garbage value, and what error to report (if any). I await your further guidance.
For the garbage value, see above. Set errno to any value you consider
sensible and document it. ERANGE would be fine with me.
So you're willing to stand behind this criterion even after I described, in a later posting, the various ways in which it was arbitrary?
Yup. I didn't buy any of your sophistry.
If this is submitted as a DR to WG14, you're willing, as it's original author and proposer, to defend it against cranky attacks by people who haven't thought through the matter as carefully as you?
Considering that the current standard doesn't impose *any* precision on
sin, I would not expect my DR to be taken seriously. Whatever
considerations led to the current committee decision would be still valid
after the submission of my DR (no precision specification is *more*
permissive than *any* precision specification).
If I were to submit a DR, it would be one requiring each implementation
to document the precision of the 4 arithmetic operations on each floating
point type. But I know, from past c.s.c discussion, that the committee
would turn a deaf ear to my DR.
Brave of you. We can call it the Pop Criterion.
Call it the common sense criterion.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
"Dan Pop" <Da*****@cern.c h> wrote in message
news:c8******** ***@sunnews.cer n.ch... : > Assume all the bits of the argument are exact and the *only* source : > of fuziness is the magnitude of the value. By the time the least : > significant bit of the mantissa means more than 2 * pi, the fuziness : > is complete (any result in the -1..1 range is correct). : > : > Is that concrete enough for you? : : Yes, it's concrete enough to show that you still don't get it.
So what you're committing to is the requirement that the sine should *not* be computed for any value where 1 ulp weighs more than 2*pi. That's too strong. I would still expect
sin(DBL_MAX) * sin(DBL_MAX) + cos(DBL_MAX) * cos(DBL_MAX)
to be reasonably close to 1.0, if not equal to it. But, other than that, any value in the [-1, 1] range is OK once 1 ulp exceeds 2*pi.
There you go again, getting un-concrete. You'll have to specify
what "reasonably " means, or some nit-picker will take apart
your revision of the sine specification. And presumably, sine should deliver the best possible approximatio n to any argument less than this magnitude.
Not even that. If the value in question covers the range [min, max], sine should provide the best possible approximation of sin(x), where x is one value in the range [min, max].
Okay, then I see no reason why we shouldn't apply this principle
to *every* math function. That would mean, for example, that
the range of permissible values can be huge for large arguments
to exp, lgamma, tgamma, as well as many combinations of arguments
to pow. (This is fine with me, since it still requires an argument reduction using about 2 1/2 words of precision, so it will break the vast majority of sine functions that have been in use for the past several decades.
Only the ones that have been *misused*. If I measure the volume of a sphere with a precision of 1 cubical centimeter, does it make any sense to compute *and display* its radius with picometer precision?
No. But if you specify the behavior of a math function and don't
provide a way to specify the uncertainty in its arguments, does
it make any sense to demand that the math functions know how
much uncertainty is there? I've been talking about the requirements
on the authors of math functions and you keep going back to how
they should be properly used. Two different universes of discourse. But hey, we're covered, so I'm happy.) Of course, you still need to specify what to return for the garbage value, and what error to report (if any). I await your further guidance.
For the garbage value, see above. Set errno to any value you consider sensible and document it. ERANGE would be fine with me.
Okay, so a programmer knows that a call to sine was silly if
1) the return value is between -1 and +1, and
2) errno indicates that some function value is either too large to
represent (overflow) or too small to represent (underflow).
That should stand up well to criticism. So you're willing to stand behind this criterion even after I described, in a later posting, the various ways in which it was arbitrary?
Yup. I didn't buy any of your sophistry.
If this is submitted as a DR to WG14, you're willing, as it's original author and proposer, to defend it against cranky attacks by people who haven't thought through the matter as carefully as you?
Considering that the current standard doesn't impose *any* precision on sin, I would not expect my DR to be taken seriously.
So that's your copout for not actually doing anything?
Whatever considerations led to the current committee decision would be still valid after the submission of my DR (no precision specification is *more* permissive than *any* precision specification).
Not even if you were brave enough to pioneer requirements on
precision in the math library? That's not too brave, given that
other languages have done so.
If I were to submit a DR, it would be one requiring each implementation to document the precision of the 4 arithmetic operations on each floating point type. But I know, from past c.s.c discussion, that the committee would turn a deaf ear to my DR.
So that's your copout for not actually doing anything? Brave of you. We can call it the Pop Criterion.
Call it the common sense criterion.
I won't call it squat if you never submit it as a DR. It's just
more idle carping.
P.J. Plauger
Dinkumware, Ltd. http://www.dinkumware.com
In article <c8***********@ sunnews.cern.ch > Da*****@cern.ch (Dan Pop) writes: In <Hx********@cwi .nl> "Dik T. Winter" <Di********@cwi .nl> writes:
To compute the precision of the result you have to do much more than is feasable in most cases.
What is the value of a result with unknown precision? To repeat my earlier example, if you don't know if it's 1 +/- 0.001 or 1 +/- 1000, the value of 1 is of pretty little use.
I have precisely stated what the result means in numerical algebra.
But if you do not trust it see that every use of linear systems with
orders about 40 is abandoned. Or look up in books by Wikinson and
Reinsch. Getting guaranteed results is very expensive. The Karlsuhe
group has even had IBM design specific extensions to their 370 to
make it even feasable.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/ This thread has been closed and replies have been disabled. Please start a new discussion. |