Re: Sine code for ANSI C
From: P.J. Plauger (pjp_at_dinkumware.com)
Date: 05/13/04
- Next message: P.J. Plauger: "Re: Sine code for ANSI C"
- Previous message: Edd: "Re: De-referencing pointer to function-pointer"
- In reply to: glen herrmannsfeldt: "Re: Sine code for ANSI C"
- Next in thread: CBFalconer: "Re: Sine code for ANSI C"
- Reply: CBFalconer: "Re: Sine code for ANSI C"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 13 May 2004 12:22:20 GMT
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:PnHoc.81199$Ik.6124808@attbi_s53...
> P.J. Plauger wrote:
> (snip)
>
> > Yes, it's concrete enough to show that you still don't get it.
>
> (snip)
>
> > 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.
>
> By returning a value you are making a claim that there is some
> sense in calculating that value. There is no sense in calculating
> such large values of radians such that the uncertainty in the
> angle is greater than pi.
You've made up a story again, about the "uncertainty" in the reduced
angle. All the library writer knows is that there's little *precision*
in the representation of that reduced angle. But it still has a well
defined value and it may well be meaningful to the customer.
> > 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.
>
> Well, small arguments it radians are easy to compute. One
> could, for example, do a numeric derivative at this point,
> say (sin(2e-38)-sin(1e-38))/(2e38-1e38) and likely get an
> exact 1.00.
You missed the point. Of *course* they're easy to compute. So
too is the sine of 1e38 quadrants -- it's zero. But should we
decide how much garbage to give back to customers based on how
easy it is for us to compute it? Suppose I make up a story that
most people who call sine with tiny arguments don't know what
the hell they're doing. I could modulate your claim above:
: By returning a value you are making a claim that there is some
: sense in calculating that value. There is no sense in calculating
: such tiny values of radians such that the magnitude of the
: angle is much less than than pi.
Who knows, maybe I could even cite studies. But in any case, I
wouldn't last long in front of a customer waving a bug report
under my nose. And I would have no defense in the C Standard.
Conjectures about the validity of input arguments just don't
cut it.
> (snip)
>
> > 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:
>
> (snip)
>
> Any of those are close enough for me.
That's nice. Would you mind writing that up as a DR? I'd love it
if the C Standard was changed to make less work for me.
> > 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.
>
> At that point, all you are saying is that the user should do
> their own argument reduction, using the appropriate method
> which only the user can know, before calling sin().
Yes, that's exactly what I'm saying. And I said it in response to
Dan Pop's claim. He alleges that taking a long time to compute the
sine of a large angle is "wasteful" of CPU cycles, even "unacceptable."
Groucho Marks: Doctor, doctor, it hurts when I do this. What should I do?
Doctor: Don't do that.
> Java, at least, defines a standard value for pi, so that programs
> can used that in generating arguments. Should you assume that
> the argument, in radians, is a multiple of that value of pi,
> or a much more accurate one?
Whatever value pi may have when truncated to machine precision
is useless for reducing arguments properly. The error shows up
after just a few radians. It's hard to defend a conjecture that
the sine of 5*pi is never worth computing properly.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
- Next message: P.J. Plauger: "Re: Sine code for ANSI C"
- Previous message: Edd: "Re: De-referencing pointer to function-pointer"
- In reply to: glen herrmannsfeldt: "Re: Sine code for ANSI C"
- Next in thread: CBFalconer: "Re: Sine code for ANSI C"
- Reply: CBFalconer: "Re: Sine code for ANSI C"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
