Re: why system providing routies will provide different result in C++ and Fortran

Ian Chivers wrote:

> my main occupation is teaching programming
> to people with little or no numeric background.
>
> the mathematical value of the cosine 90 degrees is 0 and
> the tangent of 90 degrees is infinity.
>
> to the complete beginner to programming the actual
> values returned don't make much sense.
>
> i don't claim that the values are wrong, but that they
> are not at all obvious to the beginner.
>

OK, even good trig functions can only return closest floating point
approximations - and I'm all for teaching it to all who will listen...

But on reading the sample code, my first reaction was that the much
bigger and more straightforward error would be if someone assumed that
when angles==90, that the (rational) floating point value of r could
ever be identical to pi/2 (an irrational number)....

Clearly r==pi/2 is impossible for floating point r, so a (hypothetical)
perfect precision cos function *should never* return cos(r)==0 for a
floating point value of r. Infact if it did return cos(r)==0, wouldn't
that be certain evidence that the cos function in question was not of
perfect precision...

(I think best go off to reread "What every computer scientist should
know about floating point arithmetic" myself...)

Yours,
Andy.

> "Brooks Moses" <bmoses-nospam@xxxxxxxxxxxxxxxxxx> wrote in message
> news:4328831B.1050902@xxxxxxxxxxxxxxxxxxxxx
> > Ian Chivers wrote:
> >> Here is a test program
> > [...]
> >> r=pi*angles(i)/180
> >> print *,angles(i),' ',sin(r),' ',cos(r),' ',tan(r)
> > [...]
> >> 61 0.8746197 0.4848096 1.804048
> >> 89 0.9998477 1.7452383E-02 57.29004
> >> 90 1.000000 -4.3711388E-08 -2.2877332E+07
> >> 91 0.9998477 -1.7452471E-02 -57.28975
> >>
> >> note the sign at 90 degrees of the cos and tan.
> >
> > Yes. What's wrong with it?
> >
> > Clearly, r is an approximation to pi/4 in any limited-precision
> > calculation, and thus these values are values for some angle that's nearly
> > but not exactly 90 degrees. Thus, I can't see any reason to claim that
> > either sign would be wrong here, unless you have some specific claim about
> > what side of pi/4 r happens to lie on.
> >
> > - Brooks
> >
> >
> > --
> > The "bmoses-nospam" address is valid; no unmunging needed.

.

Relevant Pages

  • Re: This calculation is just wrong / computer cant count!
    ... the path about floating point inaccuracy, but most of them can actually be educated about ... Therefore specific programming is required to cater for this. ... By analogy ALL numbers in the 17 decimal places take part in the math so 7 ... what tolerance is GT prepared to accept before black becomes grey or any ...
    (microsoft.public.vc.mfc)
  • Re: demonic problem descriptions
    ... >> do not indicate a floating point number? ... to say that the existing mechanism and notation serves a nearly ... programming languages and is not likely to change any time in the next ... why MUST i care about float ...
    (comp.lang.lisp)
  • Re: demonic problem descriptions
    ... I suspect that of all the people who have ever written floating point ... FP hardware wanted inexact math without error bounds calculation by ... Lisp enables you to do many things, ... yes, Lisp is a programmable programming language, but you shouldn't ...
    (comp.lang.lisp)
  • Re: (* 2.4 3) => 7.2000003 WTF?! Lets Fix Lisp! Noob Programming Challenge
    ... Lisp covers up the fact that there is something funky going on under the ... it would be nice if the emerging IEEE decimal floating point ... "real" number representation of programming languages were a base 10 ...
    (comp.lang.lisp)
Loading