On Fri, Dec 5, 2008 at 8:18 AM, Wacek Kusnierczyk <
Waclaw.Marcin.Kusnierczyk@idi.ntnu.no> wrote:

> well, this answer the question only partially.  this explains why a
> system with finite precision arithmetic, such as r, will fail to be
> logically correct in certain cases.  it does not explain why r, a
> language said to isolate a user from the underlying implementational
> choices, would have to fail this way.
>

Assuming you are not trolling....

There are systems which provide arbitrary (but finite) precision floating
point, exact rational arithmetic (to the limits of machine memory), and even
symbolic calculation on constant expressions like sin(2+pi/23)^2 as well as
expressions with variables such as e^-x/(x^2+1) -- for example, the Maxima
free symbolic algebra system (maxima.sourceforge.net).

The bc program is far more primitive and limited than that: it is performing
decimal *fixed*-point arithmetic (though the precision is settable), so it
may get 8.8-7.8 = 1, but (2/3)*3 => 1.99999999999999999998 and 9^-30 => 0
(with the default scale=20). So much for "logical consistency".

Exact symbolic calculation can be very useful, but Maxima (and Mathematica
and Maple etc.) has different applications and different limitations
(implementational and theoretical) from a system like R.  Though Maxima can
factor (for example) x^7+x^5+x^4+x^3-x^2-x+2 into (x+1)*(x^2-x+2)*(x^4-x+1),
and give the exact roots, it is rarely useful to know that one root is
-3^(3/4)*(2^(1/6)*%i*sqrt(((sqrt(229)*%i+3*sqrt(3))^(2/3)+4*2^(2/3))*sqrt(2^(1/3)*(sqrt(229)*%i+3*sqrt(3))^(2/3)+8)+2*2^(2/3)*3^(3/4)*sqrt(sqrt(229)*%i+3*sqrt(3)))+(2^(1/3)*(sqrt(229)*%i+3*sqrt(3))^(2/3)+8)^(3/4))/(6*2^(1/3)*(sqrt(229)*%i+3*sqrt(3))^(1/6)*(2^(1/3)*(sqrt(229)*%i+3*sqrt(3))^(2/3)+8)^(1/4));
the approximation -0.93409928946053*%i-0.7271360844912 (which Maxima can
also calculate -- to 100000 digits if you like) is more useful.

              -s

	[[alternative HTML version deleted]]

