Sine code for ANSI C

[P.J. Plauger]

Re: Sine code for ANSI C

"Dan Pop" <Dan.Pop@cern.c h> wrote in message
news:c7t116$sa8 $6@sunnews.cern .ch...[color=blue]
> In <Zy7oc.186082$L 31.13537@nwrddc 01.gnilink.net> "P.J. Plauger"[/color]
<pjp@dinkumware .com> writes:[color=blue]
>[color=green]
> >Sorry, but some of our customers are highly clued and they *do*
> >know when their floating-point numbers are fuzzy and when they're
> >not.[/color]
>
> Concrete examples, please.[/color]

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. Do
you want to be told that the return value has about 16 low-order
garbage bits because nobody could possibly expect an angle that
large to have any less fuzz? Maybe you do, but some don't. And I,
for one, have trouble justifying in this case why a standard
library function shouldn't deliver on a not-unreasonable
expectation. (The fact that it's hard to deliver on the expectation
doesn't make it unreasonable.)

P.J. Plauger
Dinkumware, Ltd.

http://www.dinkumware.com

[Dan Pop]

Re: Sine code for ANSI C

In <1dpoc.118917$G _.72884@nwrddc0 2.gnilink.net> "P.J. Plauger" <pjp@dinkumware .com> writes:
[color=blue]
>"Dan Pop" <Dan.Pop@cern.c h> wrote in message
>news:c7t116$sa 8$6@sunnews.cer n.ch...[color=green]
>> In <Zy7oc.186082$L 31.13537@nwrddc 01.gnilink.net> "P.J. Plauger"[/color]
><pjp@dinkumwar e.com> writes:[color=green]
>>[color=darkred]
>> >Sorry, but some of our customers are highly clued and they *do*
>> >know when their floating-point numbers are fuzzy and when they're
>> >not.[/color]
>>
>> Concrete examples, please.[/color]
>
>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.[/color]

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

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.

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.

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

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

[P.J. Plauger]

Re: Sine code for ANSI C

"Dan Pop" <Dan.Pop@cern.c h> wrote in message
news:c7t8i0$1sv $1@sunnews.cern .ch...
[color=blue]
> In <1dpoc.118917$G _.72884@nwrddc0 2.gnilink.net> "P.J. Plauger"[/color]
<pjp@dinkumware .com> writes:[color=blue]
>[color=green]
> >"Dan Pop" <Dan.Pop@cern.c h> wrote in message
> >news:c7t116$sa 8$6@sunnews.cer n.ch...[color=darkred]
> >> In <Zy7oc.186082$L 31.13537@nwrddc 01.gnilink.net> "P.J. Plauger"[/color]
> ><pjp@dinkumwar e.com> writes:[color=darkred]
> >>
> >> >Sorry, but some of our customers are highly clued and they *do*
> >> >know when their floating-point numbers are fuzzy and when they're
> >> >not.
> >>
> >> Concrete examples, please.[/color]
> >
> >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.[/color]
>
> You *can*, but does it make physical sense to call sine with an integer
> argument (even if represented as a float)?[/color]

Yes. It also makes sense to call sine with a double having 40 bits of
fraction *that are exact* and expect the 53-bit sine corresponding to
that exact number, regardless of whether there's also an exact integer
contribution as well. Same problem.
[color=blue]
> 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.[/color]

Not necessarily. Once again, you're presuming that everybody programs
like you do. Library vendors don't have that luxury.
[color=blue]
> 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.[/color]

And I gave one.
[color=blue]
> 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.[/color]

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.
[color=blue]
> If I call
> sin(DBL_MAX) I deserve *any* garbage in the -1..1 range, even if DBL_MAX
> is an exact integer value.[/color]

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

Fortunately for you, most sine functions meet your quality
requirements.

P.J. Plauger
Dinkumware, Ltd.

http://www.dinkumware.com

[Dan Pop]

Re: Sine code for ANSI C

In <I6qoc.64642$sK 3.2562@nwrddc03 .gnilink.net> "P.J. Plauger" <pjp@dinkumware .com> writes:
[color=blue]
>"Dan Pop" <Dan.Pop@cern.c h> wrote in message
>news:c7t8i0$1s v$1@sunnews.cer n.ch...
>[color=green]
>> In <1dpoc.118917$G _.72884@nwrddc0 2.gnilink.net> "P.J. Plauger"[/color]
><pjp@dinkumwar e.com> writes:[color=green]
>>[color=darkred]
>> >"Dan Pop" <Dan.Pop@cern.c h> wrote in message
>> >news:c7t116$sa 8$6@sunnews.cer n.ch...
>> >> In <Zy7oc.186082$L 31.13537@nwrddc 01.gnilink.net> "P.J. Plauger"
>> ><pjp@dinkumwar e.com> writes:
>> >>
>> >> >Sorry, but some of our customers are highly clued and they *do*
>> >> >know when their floating-point numbers are fuzzy and when they're
>> >> >not.
>> >>
>> >> 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.[/color]
>>
>> You *can*, but does it make physical sense to call sine with an integer
>> argument (even if represented as a float)?[/color]
>
>Yes. It also makes sense to call sine with a double having 40 bits of
>fraction *that are exact* and expect the 53-bit sine corresponding to
>that exact number, regardless of whether there's also an exact integer
>contribution as well. Same problem.[/color]

Concrete examples, please.
[color=blue][color=green]
>> 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.[/color]
>
>Not necessarily. Once again, you're presuming that everybody programs
>like you do. Library vendors don't have that luxury.[/color]

Concrete examples, please. Assuming a competent approach of the problem.
[color=blue][color=green]
>> 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.[/color]
>
>And I gave one.[/color]

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.
[color=blue][color=green]
>> 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.[/color]
>
>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.[/color]

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.
[color=blue][color=green]
>> sin(DBL_MAX) I deserve *any* garbage in the -1..1 range, even if DBL_MAX
>> is an exact integer value.[/color]
>
>Probably. You also deserve *any* number of CPU cycles spent generating
>that garbage.[/color]

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.
[color=blue]
>Fortunately for you, most sine functions meet your quality
>requirements .[/color]

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

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

[Dik T. Winter]

Re: Sine code for ANSI C

In article <c7t8i0$1sv$1@s unnews.cern.ch> Dan.Pop@cern.ch (Dan Pop) writes:[color=blue]
> In <1dpoc.118917$G _.72884@nwrddc0 2.gnilink.net> "P.J. Plauger" <pjp@dinkumware .com> writes:[/color]
....[color=blue][color=green][color=darkred]
> >> Concrete examples, please.[/color]
> >
> >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.[/color]
>
> You *can*, but does it make physical sense to call sine with an integer
> argument (even if represented as a float)?[/color]

Must everything make physical sense? Perhaps it makes mathematical sense?
[color=blue]
> 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.[/color]

Not in mathematical applications, where the argument to the sine function
can very well be exact.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[P.J. Plauger]

Re: Sine code for ANSI C

"Dan Pop" <Dan.Pop@cern.c h> wrote in message
news:c7tcmg$c30 $2@sunnews.cern .ch...
[color=blue]
> Concrete examples, please.
> .....
> Concrete examples, please. Assuming a competent approach of the problem.
> .....[color=green][color=darkred]
> >> So, I was asking about *concrete* examples where it makes sense to call
> >> sine with integral arguments or with arguments that are provably[/color][/color][/color]
*exact*[color=blue][color=green][color=darkred]
> >> representations of the intended value.[/color]
> >
> >And I gave one.[/color]
>
> 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.[/color]

The term is beyond my grasp.
[color=blue][color=green][color=darkred]
> >> 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.[/color]
> >
> >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.[/color]
>
> 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.[/color]

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.
[color=blue][color=green][color=darkred]
> >> sin(DBL_MAX) I deserve *any* garbage in the -1..1 range, even if[/color][/color][/color]
DBL_MAX[color=blue][color=green][color=darkred]
> >> is an exact integer value.[/color]
> >
> >Probably. You also deserve *any* number of CPU cycles spent generating
> >that garbage.[/color]
>
> 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.[/color]

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.
[color=blue][color=green]
> >Fortunately for you, most sine functions meet your quality
> >requirements .[/color]
>
> Glad to hear it. I hope I'll never be forced to use yours.[/color]

Me too.

P.J. Plauger
Dinkumware, Ltd.

http://www.dinkumware.com

[Dan Pop]

Re: Sine code for ANSI C

In <HxLvHG.5J@cwi. nl> "Dik T. Winter" <Dik.Winter@cwi .nl> writes:
[color=blue]
>In article <c7t8i0$1sv$1@s unnews.cern.ch> Dan.Pop@cern.ch (Dan Pop) writes:[color=green]
> > In <1dpoc.118917$G _.72884@nwrddc0 2.gnilink.net> "P.J. Plauger" <pjp@dinkumware .com> writes:[/color]
>...[color=green][color=darkred]
> > >> 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.[/color]
> >
> > You *can*, but does it make physical sense to call sine with an integer
> > argument (even if represented as a float)?[/color]
>
>Must everything make physical sense? Perhaps it makes mathematical sense?[/color]

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.
[color=blue][color=green]
> > 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.[/color]
>
>Not in mathematical applications, where the argument to the sine function
>can very well be exact.[/color]

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: Dan.Pop@ifh.de

[osmium]

Re: Sine code for ANSI C

P.J. Plauger writes:
[color=blue]
> "Dan Pop" <Dan.Pop@cern.c h> wrote in message
> news:c7tcmg$c30 $2@sunnews.cern .ch...
>[color=green]
> > Concrete examples, please.
> > .....
> > Concrete examples, please. Assuming a competent approach of the[/color][/color]
problem.[color=blue][color=green]
> > .....[color=darkred]
> > >> So, I was asking about *concrete* examples where it makes sense to[/color][/color][/color]
call[color=blue][color=green][color=darkred]
> > >> sine with integral arguments or with arguments that are provably[/color][/color]
> *exact*[color=green][color=darkred]
> > >> representations of the intended value.
> > >
> > >And I gave one.[/color]
> >
> > 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.[/color][/color]

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.

[Dan Pop]

Re: Sine code for ANSI C

In <Diroc.188998$L 31.28081@nwrddc 01.gnilink.net> "P.J. Plauger" <pjp@dinkumware .com> writes:
[color=blue]
>"Dan Pop" <Dan.Pop@cern.c h> wrote in message
>news:c7tcmg$c3 0$2@sunnews.cer n.ch...
>[color=green]
>> 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.[/color]
>
>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.[/color]

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: Dan.Pop@ifh.de

[Dan Pop]

Re: Sine code for ANSI C

In <2gf1o5F26s5jU1 @uni-berlin.de> "osmium" <r124c4u102@com cast.net> writes:
[color=blue]
>P.J. Plauger writes:
>[color=green]
>> "Dan Pop" <Dan.Pop@cern.c h> wrote in message
>> news:c7tcmg$c30 $2@sunnews.cern .ch...
>>[color=darkred]
>> > Concrete examples, please.
>> > .....
>> > Concrete examples, please. Assuming a competent approach of the[/color][/color]
>problem.[color=green][color=darkred]
>> > .....
>> > >> So, I was asking about *concrete* examples where it makes sense to[/color][/color]
>call[color=green][color=darkred]
>> > >> sine with integral arguments or with arguments that are provably[/color]
>> *exact*[color=darkred]
>> > >> 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.[/color][/color]
>
>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.[/color]

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: Dan.Pop@ifh.de

[osmium]

Re: Sine code for ANSI C

Dan Pop writes:
[color=blue]
> In <2gf1o5F26s5jU1 @uni-berlin.de> "osmium" <r124c4u102@com cast.net>[/color]
writes:[color=blue]
>[color=green]
> >P.J. Plauger writes:
> >[color=darkred]
> >> "Dan Pop" <Dan.Pop@cern.c h> wrote in message
> >> news:c7tcmg$c30 $2@sunnews.cern .ch...
> >>
> >> > Concrete examples, please.
> >> > .....
> >> > Concrete examples, please. Assuming a competent approach of the[/color]
> >problem.[color=darkred]
> >> > .....
> >> > >> So, I was asking about *concrete* examples where it makes sense to[/color]
> >call[color=darkred]
> >> > >> 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[/color][/color][/color]
maybe[color=blue][color=green][color=darkred]
> >> > the term is beyond your grasp... Clue: "concrete" and "hypothetic al"
> >> > are not exactly synonyms in any language I'm familiar with.[/color]
> >
> >You might mention to Mr. Pop the notion of a revolution counter, such as[/color][/color]
a[color=blue][color=green]
> >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.[/color][/color]
If[color=blue][color=green]
> >Dan Pop needs the name of a particular ship to make the point[/color][/color]
sufficiently[color=blue][color=green]
> >concrete, I expect some one could provide the name of such a ship.[/color]
>
> 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.[/color]

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.

[Dan Pop]

Re: Sine code for ANSI C

In <2gf53sF277itU1 @uni-berlin.de> "osmium" <r124c4u102@com cast.net> writes:
[color=blue]
>Dan Pop writes:
>[color=green]
>> In <2gf1o5F26s5jU1 @uni-berlin.de> "osmium" <r124c4u102@com cast.net>[/color]
>writes:[color=green]
>>[color=darkred]
>> >P.J. Plauger writes:
>> >
>> >> "Dan Pop" <Dan.Pop@cern.c h> wrote in message
>> >> news:c7tcmg$c30 $2@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[/color][/color]
>maybe[color=green][color=darkred]
>> >> > 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[/color][/color]
>a[color=green][color=darkred]
>> >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.[/color][/color]
>If[color=green][color=darkred]
>> >Dan Pop needs the name of a particular ship to make the point[/color][/color]
>sufficiently[color=green][color=darkred]
>> >concrete, I expect some one could provide the name of such a ship.[/color]
>>
>> 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.[/color]
>
>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.[/color]

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: Dan.Pop@ifh.de

[P.J. Plauger]

Re: Sine code for ANSI C

"Dan Pop" <Dan.Pop@cern.c h> wrote in message
news:c7tiir$qa2 $1@sunnews.cern .ch...
[color=blue]
> In <Diroc.188998$L 31.28081@nwrddc 01.gnilink.net> "P.J. Plauger"[/color]
<pjp@dinkumware .com> writes:[color=blue]
>[color=green]
> >"Dan Pop" <Dan.Pop@cern.c h> wrote in message
> >news:c7tcmg$c3 0$2@sunnews.cer n.ch...
> >[color=darkred]
> >> 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.[/color]
> >
> >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.[/color]
>
> 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?[/color]

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:
[color=blue][color=green][color=darkred]
> >> 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.[/color][/color][/color]

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

[CBFalconer]

Re: Sine code for ANSI C

"P.J. Plauger" wrote:[color=blue]
>[/color]
.... snip ...[color=blue]
>
> 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.[/color]

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?

[P.J. Plauger]

Re: Sine code for ANSI C

"CBFalconer " <cbfalconer@yah oo.com> wrote in message
news:40A26514.5 B3E3582@yahoo.c om...
[color=blue]
> "P.J. Plauger" wrote:[color=green]
> >[/color]
> ... snip ...[color=green]
> >
> > 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.[/color]
>
> 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.[/color]

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

Thanks,

P.J. Plauger
Dinkumware, Ltd.

http://www.dinkumware.com