Aha, apparently you meant:
%%HP: T(3)A(R)F(.);
'\pi*\.S(1,1000,INV(SQ(x)),x)'
(I'm using the "backslash" character translations here, so "\pi"
represents the lower-case Greek letter pi, "\.S" represents the integral
symbol, "\->" represents the right-arrow, and "\.d" represents the
derivative symbol.)
instead of:
'PI*Int(1,10000,(INV(SQ(x)),x)'
For a while there, I was thinking that by "Int" you meant "INT".
Flag settings (besides exact/approximate) that I think *may* be relevant
are:
-2 clear (Constant \-> symb)
-3 clear (Function \-> symb)
and in the 49G:
-99 clear (CAS:quiet)
-100 clear (Step by step off)
-120 set (Silent mode on)
-123 clear (Allow Switch Mode)
All of the times are for a single trial each, and should be considered
to be approximate.
I thought that it would be best to get the algebraic evaluated all the
way to a numeric value in one step, so I used \->NUM instead of EVAL. It
turned out that that wasn't such a good idea.
A 48SX returned 3.13845106094 in 433_s.
A 48GX returned 3.13845106094 in 293_s.
A 49G in approximate mode returned 3.13845106094 in 369_s.
A 49G in exact mode returned 3.13845106094 in 369_s.
By "trailing decimal", I meant:
%%HP: T(3)A(R)F(.);
'\pi*\.S(1.,1000.,INV(SQ(x)),x)'
Which causes the 49G to treat the numbers as type 0 floating point
numbers ("real" numbers, in RPL jargon) instead of type 28 exact
integers.
A 49G in approximate mode with reals returned 3.13845106094 in 369_s.
A 49G in exact mode with reals returned 3.13845106094 in 369_s.
BUT...
Using EVAL, the 48SX returned:
'\pi*(-INV(x)/\.dx(x)|(x=1000)-(-INV(x)'/\.dx(x)|(x=1)))'
in 1.49_s.
EVAL on that returned:
'\pi*.999'
in 1.12_s.
\->NUM on that returned 3.13845106094 in .0132_s.
Using EVAL, the 48GX returned:
'\pi*(-INV(x)/\.dx(x)|(x=1000)-(-INV(x)'/\.dx(x)|(x=1)))'
in 1.05_s.
EVAL on that returned:
'\pi*.999'
in .793_s.
\->NUM on that returned 3.13845106094 in .0092_s.
Using EVAL, the 49G in approximate mode with exact integers returned
3.13845106094 in 365_s.
Using EVAL, the 49G in exact mode with exact integers returned:
'(999*\pi)/1000'
in 3.54_s.
\->NUM on that returned 3.13845106094 in .157_s.
Using EVAL, the 49G in approximate mode with reals returned
3.13845106094 in 365_s.
Using EVAL, the 49G in exact mode with reals returned:
'.999*\pi'
in 3.04_s and left the 49G in approximate mode.
EVAL on that returned 3.13845106094 in .0779_s
Go figure....
It looks to me as if the best strategy is to use EVAL (and in the 49G,
exact mode) to solve symbolically as far as possible, and only then
force a numeric result. And for "real work", I think I'll keep using the
48 series.
Regards,
James