Re: Sine code for ANSI C

From: glen herrmannsfeldt (gah_at_ugcs.caltech.edu)
Date: 05/14/04

  • Next message: Dave Hansen: "Re: if(a);" 
    Date: Fri, 14 May 2004 19:28:06 GMT

    P.J. Plauger wrote:
    > "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
    > news:V7Xoc.6287$6f5.499223@attbi_s54...

    >>Consider this program fragment, as no real examples have
    >>been presented so far:

    >>for(x=0;x+60!=x;x+=60) printf("%20.15g\n",sin(x*A));

    (snip)

    > Okay, so what? The programmer has unrealistic expectations.
    > It's the library vendor's responsibility to meet possibly
    > realistic expectations. The vendor can't possibly guess
    > all the ways that library functions will be called with
    > arguments that need "correcting" so as not to hurt the
    > programmer's feelings.

    That example is more realistic than any you have posted
    so far.

    > What does this tell the designer of a sine function about
    > where it's okay to stop delivering accurate results?

    (snip)

    >>Consider someone doing a single precision sine. Most
    >>likely they use single precision instead of double
    >>because they don't need so much accuracy and hope that
    >>the result will be generated faster.

    > Most likely.

    > What does this tell the designer of a sine function about
    > where it's okay to stop delivering accurate results?

    When they use a single precision function they expect
    less accurate answers than a double precision function.

    >>As there are plenty of multiple precision libraries
    >>around, users wanting more than machine precision
    >>know where to find it.

    > Okay.

    > What does this tell the designer of a sine function about
    > where it's okay to stop delivering accurate results?

    It says that when the operations require exceptional
    ability to perform, far above and beyond the call of
    duty, it is time to give up. When thousands of
    digits of pi are required to compute the result on
    a 64 bit operand, something is wrong.

    >>The OS/360 math library writers had to work extra hard
    >>to get accurate results given the base 16 floating
    >>point of S/360. Sometimes it took a little extra work
    >>to get good answers, which is fine. (The last iteration
    >>on the square root algorithm is done slightly different
    >>to avoid precision loss in a halve operation.) A lot of
    >>extra work to get useless answers is not. (The sine
    >>routine gives a fatal error when the argument is greater
    >>than pi*2**18 (single), pi*2**50 (double), or pi*2**100
    >>(extended precision).

    > Nice criteria. I don't see them anywhere in the C Standard.
    > Are you going to propose them as a DR? Be fun to see you
    > defend why you pick the exponent 18 for 24-bit (IEEE)
    > precision, 50 for 53-bit and 100 for 64-bit(!) or 113-bit.

    The requirements of the C standard have already been
    discussed, and that didn't seem to bother you any.

    The numbers above are not for IEEE, as it hadn't been
    invented yet. Extended precision has 112 bit fraction.

    > And what "fatal" error are you going to introduce, given that
    > the math library currently has no such concept. Even IEEE 654
    > always provides for continuing execution with some error
    > code. Looks like you're bravely guiding the standards community
    > into new and uncharted territory. Brave of you.

    It seems that on most implementations sqrt() has the
    ability to generate a fatal error when given a negative
    argument.

    >>Giving a fatal error tells the user that something is
    >>wrong and should be fixed.

    > Can you quantify the "wrongness" in terms of your criteria?
    > Should they not also be applied to the various rounding
    > functions? If not, why not?

    There are no problems of any use to anyone where they
    are useful.

    (snip)

    > Happens all the time, when users call math functions with
    > arguments having bits that don't really exist. Just whose
    > responsibility is that, anyway?

    >>Actually, the time when this happened to me, probably
    >>when I was in ninth grade, (due to an undefined variable
    >>if I remember right), someone carefully explained to me
    >>why the library would refuse such a calculation. It made
    >>sense at the time, and it still does.

    > Things that make sense for a ninth-grade class don't necessarily
    > scale to professional libraries licensed to professional
    > programmers, both working to language standards developed
    > by international organizations.

    It wasn't in a class. They didn't teach it in ninth grade,
    and as far as I know they don't now. It was explained to
    me by a professional physicist.

    -- glen

  • Next message: Dave Hansen: "Re: if(a);"

    Relevant Pages

    • Re: About the accuarcy of SSE calculations
      ... > changed by libraries. ... It is true that a library could change the FPU control word, ... could either increase or decrease precision. ...
      (comp.lang.asm.x86)
    • Re: Compiling SPECFUN and similar libraries
      ... CD DOUBLE PRECISION ... libraries, I was wondering if there is some standard Unix utility ...
      (comp.lang.fortran)
    • Re: RFC: Building the Perfect Tabbed Pane (an tutorial article)
      ... var isRealObjectProperty = function{ ... You know that the getAnElement variable exists. ... I cannot blame people for using the mainstream libraries. ...
      (comp.lang.javascript)
    • Re: How to list the statement of all var ?
      ... but as it is a command line tool it does not have access to a browser DOM ... > implementations based on language features of JavaScript 1.1 and JScript ... > script libraries which also ...
      (comp.lang.javascript)
    • Re: Just one more anecdote
      ... <big snip> ... I say this because everything you mention above, and the ordered lists you ... libraries to keep the user/programmer from worrying about it. ... My own choice when confronting these realities was that SQL products (not ...
      (comp.databases.theory)