473,889 Members | 1,803 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Sine code for ANSI C

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 8142
"Dan Pop" <Da*****@cern.c h> wrote in message
news:c7******** **@sunnews.cern .ch...
Concrete examples, please.
.....
Concrete examples, please. Assuming a competent approach of the problem.
.....
So, I was asking about *concrete* examples where it makes sense to call
sine with integral arguments or with arguments that are provably *exact* representations of the intended value.


And I gave one.


Nope, you gave me nothing in the way of a *concrete* example. Or maybe
the term is beyond your grasp... Clue: "concrete" and "hypothetic al"
are not exactly synonyms in any language I'm familiar with.


The term is beyond my grasp.
To *me*, as a user, having a sine that spends CPU cycles to provide
the answer with the precision implied by the assumption that the
argument represents an exact value, is unacceptable.


What if the cycles are spent only on large arguments? All you have
to do then is avoid the large arguments you know to be meaningless
in your application.


Even not so large arguments can still have plenty of fuziness and
getting a 53-bit accurate answer for the value actually represented is
still a waste of CPU resources.


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.
sin(DBL_MAX) I deserve *any* garbage in the -1..1 range, even if DBL_MAX is an exact integer value.


Probably. You also deserve *any* number of CPU cycles spent generating
that garbage.


A *good* implementation (which is what we're talking about, right?) is
supposed to produce garbage (where garbage is asked for) as fast as
possible.


I agree that it's a Quality of Implementation issue just how fast a
library function supplies nonsense when called with nonsense arguments.
But I've yet to hear an objective criterion for determining how much
of an argument is garbage. Absent that, the best way I know for library
writers to satisfy customers is to assume that every input value is
exact, and to produce the closest possible representation to the nearest
internal representation of the corresponding function value.

Of course, if you don't want to take responsibility for analyzing error
propagation, that's fine. Just don't foist the burden on somebody who
doesn't know how fuzzy your inputs really are.
Fortunately for you, most sine functions meet your quality
requirements .


Glad to hear it. I hope I'll never be forced to use yours.


Me too.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Nov 14 '05 #51
In <Hx*******@cwi. nl> "Dik T. Winter" <Di********@cwi .nl> writes:
In article <c7**********@s unnews.cern.ch> Da*****@cern.ch (Dan Pop) writes:
In <1d************ *******@nwrddc0 2.gnilink.net> "P.J. Plauger" <pj*@dinkumware .com> writes:

...
> Concrete examples, please.

What is the sine of 162,873 radians? If you're working in radians,
you can represent this input value *exactly* even in a float.


You *can*, but does it make physical sense to call sine with an integer
argument (even if represented as a float)?


Must everything make physical sense? Perhaps it makes mathematical sense?


And does it? Last time I checked, mathematics define the sine as having
a real argument and the C programming language provides zilch support for
real numbers.
In real life applications, the argument of sine is computed using
floating point arithmetic (on non-integer values), so it *is* a fuzzy
value, with the degree of fuzziness implied by its magnitude.


Not in mathematical applications, where the argument to the sine function
can very well be exact.


Please elaborate, again, with concrete examples. Where do these
"mathematic al applications" get their input data from? How do they
handle the *incorrect* (from the mathematics POV) result of calling sine
for pretty much *any* argument except 0?

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #52
P.J. Plauger writes:
"Dan Pop" <Da*****@cern.c h> wrote in message
news:c7******** **@sunnews.cern .ch...
Concrete examples, please.
.....
Concrete examples, please. Assuming a competent approach of the problem.
.....
> So, I was asking about *concrete* examples where it makes sense to call> sine with integral arguments or with arguments that are provably

*exact*> representations of the intended value.

And I gave one.


Nope, you gave me nothing in the way of a *concrete* example. Or maybe
the term is beyond your grasp... Clue: "concrete" and "hypothetic al"
are not exactly synonyms in any language I'm familiar with.


You might mention to Mr. Pop the notion of a revolution counter, such as a
Veeder-Root counter on the propeller shaft of an ocean going ship. My
guess is that there are a lot of radians between England and New Jersey. If
Dan Pop needs the name of a particular ship to make the point sufficiently
concrete, I expect some one could provide the name of such a ship.


Nov 14 '05 #53
In <Di************ ********@nwrddc 01.gnilink.net> "P.J. Plauger" <pj*@dinkumware .com> writes:
"Dan Pop" <Da*****@cern.c h> wrote in message
news:c7******* ***@sunnews.cer n.ch...
Even not so large arguments can still have plenty of fuziness and
getting a 53-bit accurate answer for the value actually represented is
still a waste of CPU resources.


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?

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #54
In <2g************ @uni-berlin.de> "osmium" <r1********@com cast.net> writes:
P.J. Plauger writes:
"Dan Pop" <Da*****@cern.c h> wrote in message
news:c7******** **@sunnews.cern .ch...
> Concrete examples, please.
> .....
> Concrete examples, please. Assuming a competent approach of theproblem. > .....
> >> So, I was asking about *concrete* examples where it makes sense tocall > >> sine with integral arguments or with arguments that are provably

*exact*
> >> representations of the intended value.
> >
> >And I gave one.
>
> Nope, you gave me nothing in the way of a *concrete* example. Or maybe
> the term is beyond your grasp... Clue: "concrete" and "hypothetic al"
> are not exactly synonyms in any language I'm familiar with.


You might mention to Mr. Pop the notion of a revolution counter, such as a
Veeder-Root counter on the propeller shaft of an ocean going ship. My
guess is that there are a lot of radians between England and New Jersey. If
Dan Pop needs the name of a particular ship to make the point sufficiently
concrete, I expect some one could provide the name of such a ship.


You may also want to mention a concrete example where applying the sine
function to such a revolution counter makes sense. Unless I'm missing
something, only the last, possibly incomplete, revolution counts in the
context of the sine function, so please clue me in.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #55
Dan Pop writes:
In <2g************ @uni-berlin.de> "osmium" <r1********@com cast.net> writes:
P.J. Plauger writes:
"Dan Pop" <Da*****@cern.c h> wrote in message
news:c7******** **@sunnews.cern .ch...

> Concrete examples, please.
> .....
> Concrete examples, please. Assuming a competent approach of the

problem.
> .....
> >> So, I was asking about *concrete* examples where it makes sense to

call
> >> sine with integral arguments or with arguments that are provably
*exact*
> >> representations of the intended value.
> >
> >And I gave one.
>
> Nope, you gave me nothing in the way of a *concrete* example. Or maybe > the term is beyond your grasp... Clue: "concrete" and "hypothetic al"
> are not exactly synonyms in any language I'm familiar with.


You might mention to Mr. Pop the notion of a revolution counter, such as aVeeder-Root counter on the propeller shaft of an ocean going ship. My
guess is that there are a lot of radians between England and New Jersey. IfDan Pop needs the name of a particular ship to make the point sufficientlyconcrete, I expect some one could provide the name of such a ship.


You may also want to mention a concrete example where applying the sine
function to such a revolution counter makes sense. Unless I'm missing
something, only the last, possibly incomplete, revolution counts in the
context of the sine function, so please clue me in.


When I was a child I said, "prime numbers, what are they good for?" Now
finally I, and a lot of other people know what they are good for. For a
mathematician sitting in an ivory tower to decide which equations make sense
and which are worth solving is the height of arrogance. My reading is that
that is the point P.J. Plauger has been trying to make. The world is so
complex that the work load must be divided amongst several heads. P.J. does
his mathematician thing and engineers do their engineering thing. When his
fussiness causes his sine routine to take 50 msec when Intel does it in 2
pico seconds, we might revisit the problem. I don't think we are there yet.
Nov 14 '05 #56
In <2g************ @uni-berlin.de> "osmium" <r1********@com cast.net> writes:
Dan Pop writes:
In <2g************ @uni-berlin.de> "osmium" <r1********@com cast.net>

writes:
>P.J. Plauger writes:
>
>> "Dan Pop" <Da*****@cern.c h> wrote in message
>> news:c7******** **@sunnews.cern .ch...
>>
>> > Concrete examples, please.
>> > .....
>> > Concrete examples, please. Assuming a competent approach of the
>problem.
>> > .....
>> > >> So, I was asking about *concrete* examples where it makes sense to
>call
>> > >> sine with integral arguments or with arguments that are provably
>> *exact*
>> > >> representations of the intended value.
>> > >
>> > >And I gave one.
>> >
>> > Nope, you gave me nothing in the way of a *concrete* example. Ormaybe >> > the term is beyond your grasp... Clue: "concrete" and "hypothetic al"
>> > are not exactly synonyms in any language I'm familiar with.
>
>You might mention to Mr. Pop the notion of a revolution counter, such asa >Veeder-Root counter on the propeller shaft of an ocean going ship. My
>guess is that there are a lot of radians between England and New Jersey.If >Dan Pop needs the name of a particular ship to make the pointsufficiently >concrete, I expect some one could provide the name of such a ship.


You may also want to mention a concrete example where applying the sine
function to such a revolution counter makes sense. Unless I'm missing
something, only the last, possibly incomplete, revolution counts in the
context of the sine function, so please clue me in.


When I was a child I said, "prime numbers, what are they good for?" Now
finally I, and a lot of other people know what they are good for. For a
mathematicia n sitting in an ivory tower to decide which equations make sense
and which are worth solving is the height of arrogance. My reading is that
that is the point P.J. Plauger has been trying to make. The world is so
complex that the work load must be divided amongst several heads. P.J. does
his mathematician thing and engineers do their engineering thing. When his
fussiness causes his sine routine to take 50 msec when Intel does it in 2
pico seconds, we might revisit the problem. I don't think we are there yet.


I somehow failed to find in this empty verbiage the answer to the concrete
question I was asking in my previous post...

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #57
"Dan Pop" <Da*****@cern.c h> wrote in message
news:c7******** **@sunnews.cern .ch...
In <Di************ ********@nwrddc 01.gnilink.net> "P.J. Plauger" <pj*@dinkumware .com> writes:
"Dan Pop" <Da*****@cern.c h> wrote in message
news:c7******* ***@sunnews.cer n.ch...
Even not so large arguments can still have plenty of fuziness and
getting a 53-bit accurate answer for the value actually represented is
still a waste of CPU resources.


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.

If the argument were in quadrants, I'd agree that for sufficiently
large arguments the answer is always one of {0, 1, -1}, and for
still larger arguments the answer is always zero. You'd still
want to return the appropriate member of this simple set, just as you
want to return 1e38 from the round function when called with 1e38.
Here, round is operating nowhere near its most interesting range,
but there's still a well defined function value for each input value,
and it's not the place of the library to set the Uninteresting Argument
Exception in the FPP, or set errno to EUNINTERESTING_ ARGUMENT.

The argument to sine is not really in quadrants, but in radians.
That means that even when there are no fraction bits represented in
the argument x, there *still are* in x/(pi/2) (which is how you convert
radians to quadrants). So each argument value still corresponds to
some reduced argument that can be expressed to full machine precision
(almost always as some value other than {1, 0, -1} but still computable
with enough hard work). Which means that there's a corresponding
function return value that's also computable to full machine precision
that you really ought to return.

You may think that it's unlikely that all the bits of that value are
meaningful in a given application, and you're probably right. But
you're not *definitely* right. So as a library vendor, best engineering
practice is to supply all the bits that *might* make sense, in case
they actually do. A good quality implementation will continue to
compute the sine of small arguments quickly, but if it has to take
progressively longer to reduce ever larger arguments, then so be it.
You don't want the cost, reduce the arguments quickly, by your own
crude methods that are good enough for your application, before calling
sine.

Note also that even sin(1e-38) *might not* be good to full precision,
because the argument happens not to be good to full precision, but
you have no criterion for judging how many bits are worth computing.
Since it's so easy to compute them, and since they're often all
meaningful, nobody wastes much time debating the cost of producing
bits that are potentially garbage.

Now it so happens that it gets progressively *much* harder to follow
this best engineering practice as x gets larger in magnitude. The
temptation is strong to decree that the bits are meaningless beyond
some point and just return garbage. I've done this very thing in the
past, but I'm less inclined to do it now -- at least not without some
sanctioned way to report significance loss in lieu of computing a
difficult function value.

You also didn't get that you're still not giving a sufficiently concrete
criterion for when the sine function should stop trying. If you don't
like that a sine function wastes your program microseconds computing
what you shouldn't have told it to compute, then you need to be more
precise about where it can and should give up. You state above that
the function result is definitely meaningless once 1 ulp in the argument
weighs more than 2*pi, but why go that far? Aside from a phase factor,
you've lost all angle information at pi/2. But then how meaningful is it
to have just a couple of bits of fraction information? To repeat what
you stated above:
Even not so large arguments can still have plenty of fuziness and
getting a 53-bit accurate answer for the value actually represented is
still a waste of CPU resources.


So you've taken on a serious responsibility here. You have to tell us
library vendors just how small "not so large" is, so we know where to
produce quick garbage instead of slower correct answers. If you don't,
you have no right to deem our products unacceptable, or even simply
wasteful.

Of course, you also need to get some standards organization to agree
with you, so we all have the same *concrete* criteria to obey. But I'm
sure you can sweet talk one of them into doing as you say, once you
actually say it.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Nov 14 '05 #58
"P.J. Plauger" wrote:
.... snip ...
I agree that it's a Quality of Implementation issue just how fast
a library function supplies nonsense when called with nonsense
arguments. But I've yet to hear an objective criterion for
determining how much of an argument is garbage. Absent that, the
best way I know for library writers to satisfy customers is to
assume that every input value is exact, and to produce the
closest possible representation to the nearest internal
representation of the corresponding function value.

Of course, if you don't want to take responsibility for analyzing
error propagation, that's fine. Just don't foist the burden on
somebody who doesn't know how fuzzy your inputs really are.


I am gradually coming around to your point of view here, so I am
rewording it. To me, the argument is that the input argument
represents a range of values (absent contrary information) with a
known uncertainty. The most probable actual value is the exact
value. Since d(sinx)/dx is strictly bounded, the resultant
function is never going to fly off in all directions, and will not
become totally meaningless unless that argument uncertainty is in
the order of PI.

We can, at the cost of some computational complexity, assume the
input argument is exact and reduce it to a principal value with an
accuracy governed by the precision of PI. There is no essential
difference between this operation and forming a real value for
1/3. The critical thing there is the precision of our knowledge
of 3.

For a concrete example, consider a mechanism that rotates and
detents at 45 degree intervals. The sine of the resultant angle
can only have 5 discrete values. However the net rotation is
described by the sum of a counter (of full turns) and one of 8
discrete angles, in units of 45 deg. After letting that engine
whir for a day and a half at a 1000 rpm and a half and recording
the final angle, we want to know the sine of that angle. The
computation machinery knows nothing about detents, all it has to
work with is PI, the net rotation angle, and the computation
algorithm for sin(x).

At some point the accuracy of the results will become worse than
the accuracy of the detents, and all blows up. This is not the
same point as that reached by simple modulo PI arithmetic.

--
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?
Nov 14 '05 #59
"CBFalconer " <cb********@yah oo.com> wrote in message
news:40******** *******@yahoo.c om...
"P.J. Plauger" wrote:

... snip ...

I agree that it's a Quality of Implementation issue just how fast
a library function supplies nonsense when called with nonsense
arguments. But I've yet to hear an objective criterion for
determining how much of an argument is garbage. Absent that, the
best way I know for library writers to satisfy customers is to
assume that every input value is exact, and to produce the
closest possible representation to the nearest internal
representation of the corresponding function value.

Of course, if you don't want to take responsibility for analyzing
error propagation, that's fine. Just don't foist the burden on
somebody who doesn't know how fuzzy your inputs really are.


I am gradually coming around to your point of view here, so I am
rewording it. To me, the argument is that the input argument
represents a range of values (absent contrary information) with a
known uncertainty. The most probable actual value is the exact
value. Since d(sinx)/dx is strictly bounded, the resultant
function is never going to fly off in all directions, and will not
become totally meaningless unless that argument uncertainty is in
the order of PI.

We can, at the cost of some computational complexity, assume the
input argument is exact and reduce it to a principal value with an
accuracy governed by the precision of PI. There is no essential
difference between this operation and forming a real value for
1/3. The critical thing there is the precision of our knowledge
of 3.

For a concrete example, consider a mechanism that rotates and
detents at 45 degree intervals. The sine of the resultant angle
can only have 5 discrete values. However the net rotation is
described by the sum of a counter (of full turns) and one of 8
discrete angles, in units of 45 deg. After letting that engine
whir for a day and a half at a 1000 rpm and a half and recording
the final angle, we want to know the sine of that angle. The
computation machinery knows nothing about detents, all it has to
work with is PI, the net rotation angle, and the computation
algorithm for sin(x).

At some point the accuracy of the results will become worse than
the accuracy of the detents, and all blows up. This is not the
same point as that reached by simple modulo PI arithmetic.


I think that you're saying a close approximation to what I've
said.

Thanks,

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Nov 14 '05 #60

This thread has been closed and replies have been disabled. Please start a new discussion.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.