Conference rusure::math

It's very inaccurate.  Spoiler follows


The correct answer is:    -54767/66192

Or, to 6 decimal places:  -0.827396

    Interesting, the ALL-IN-1 desk calculator agrees with the 4361.
    However, even though I can't see the wicked glint in the eye of the
    person who orinally posed this, I assume that means they both fell into
    the same truncation trap.
    
    Or does everything except the last term really cancel out? It's not
    immediately obvious why.
    
    Dick
    

The correct result, -54767/66192, can be obtained either from MAPLE or VAX 
LISP (or other tools with extended arithmetic). The usual result is 
actually the value of the last term, a/2b, because everything else is 
astronomically large and cancels out within the precision available to 
machine floating-point arithmetic.

The expression was (first?) published in an IBM paper on ACRITH, the 
extended-precision arithmetic package; I saw it in the anthology 
*Scientific Computing with Automatic Result Verification*, publ. Springer-
Verlag 1988, Kerlisch & Stetter, Editors., in a paper by Fischer et al,
"Evaluation of Arithmetic Expressions with Guaranteed High Accuracy". A gem 
from this paper is an algorithm for evaluating such expressions in interval 
arithmetic, using the language PASCAL-SC (PASCAL for Sci. Comp.), which 
brackets the solution within +-10^-8 in three iterations.

Even as sophisticated a tool as MAPLE can crash badly on an ill-conditioned
problem like this, if not used wisely. MAPLE handles rational arithmetic
very well, but floating-point rather feebly, so typing the expression for c
as given results in .500000000*10^28! You have to express the constants as
33325/100 and 55/10, and a,b without decimal points, to get the full power
available. 

    Here's another one, not quite so spectacular but illustrating an
    important but little known caveat:
    
    Solve the following for X:
    
    	(X^2 + 1)*log((a+b)/(a+b^2)) + exp(a+b)*X = 0
    
    where a=11 and b = 1/2.
    
    					Topher

    
    	Are we talking real numbers here ? the stated 
    	problem doesn't have a real number as an answer.

>    Solve the following for X:
>    
>    	(X^2 + 1)*log((a+b)/(a+b^2)) + exp(a+b)*X = 0
>    
>    where a=11 and b = 1/2.

There are two solutions: approximately
	               -6
        X = -.222648+*10 
and	X = -4491386.777+

of which the first has only about 6 sig figs although based on 30-digit
arithmetic (thanks to MAPLE.) - VAX double precision yields 0. as the 
first answer. Big rounding errors.

    
          How did you test your answers fro correctness?
    
    	As X^2 + 1 >1 and (a+b)/(a+b^2) >1 which in turn makes
    	log  ((a+b)/(a+b^2)) > 0 and exp(a+b)*X >= 0 (always)
    	therefore no solution exist for the problem.
    
    			Hank
    

RE .7 (Hank)
    
    The requirement for there to be at least one real root for a quadratic
    is for:
    
    			B^2 >= 4*A*C
    
    In this case it translates to:
    
    			exp(a+b) >= 4*log((a+b)/(a+b^2))
    
    exp(a+b) is approximately 10^5, while log((a+b)/(a+b^2)) is about 10^-2
    (using common logrithms, which I used when I worked out the problem,
    but forgot to specify; although it doesn't really matter to the result)
    or about twice that using natural logs.  Obviously this qualifies.
    
    					Topher

... and exp(a+b)*X >= 0 (always) ...

Not if X<0. Perhaps you read that as exp((a+b)*X).

    My fault I read the expression incorrectly as Lynn stated in previous
    reply.
    
    

    Here's a couple of well-known examples:

	exp(pi*sqrt(163/9)) ~= 640320

	exp(pi*sqrt(163)) ~= 262537412640768744

    - Jim

>>    Here's a couple of well-known examples:
>>
>>	exp(pi*sqrt(163/9)) ~= 640320

	In VAX LISP, (exp (* pi (sqrt (float 163/9 0.0l0)))) ==>
	640320.00000000060486373504901604L0.

>>	exp(pi*sqrt(163)) ~= 262537412640768744

	Also in VAX LISP, (exp (* pi (sqrt 163.0l0))) ==>
	2.62537412640768743999999999999251L17; subtracting same
	from 262537412640768744 left 7.49178497017055633477866649627686L-13.

	Dan