I'm referring here to Chuck's arc length problem which can be found here: Link to archive.

The 28S solver and integrator work differently than in the later machines. Notably, integration can't be used as an algebraic function because it returns two values to the stack, the solution and the error.

**Failed algebraic attempt**

My first attempt was to create a wrapper to make integration an algebraic function:

<<The local variables fn, var, xl and xh aren't neccessary if you want to execute INTFN from the stack, because the values are fetched from the stack to fill the variables and are than put back in the same order. But the overhead is required by the algebraic syntax.

<< -> fn var xl xh eps

<< fn

var xl xh 3 ->LIST

eps

S

DROP

>>

>>

>>

'INTFN' STO

INTFN can be called like this:

'INTFN(Due to the algebraic overhead, the function is relatively slow.v/(1+4*SQ(T)),T,0,2.3,.0001)'

EVAL

Now enter the solver menu:

'INTFN(The resulting variables screen shows 'EPS', 'T' and 'X' as variables. In the parameterlist of INTFN, 'T' is a formal parameter, but the solver logic fails to see this and complains about an unset variable 'T' when I try to solve for 'X'. If I assign a value to 'T', integration fails bacause T is no longer accepted as a formal variable.v/(1+4*SQ(T)),T,0,X,EPS)-6'

STEQ

SOLVR

So this is a dead end. :-(

**RPL solution**

I decided that I had to go the RPL way. Integration works without a formal variable if the integrand is a program. Here is my solution:

<< -> x eps

<<

<< SQ 4 * 1 +v/>>

{ 0 x }

eps

S

DROP

>>

>>

'FN' STO

FN can be called as an algebraic:

'FN(2.3,.0001)'This is faster than the original INTFN version.

EVAL

Now enter the solver menu:

'FN(X,EPS)-6'The resulting variables screen shows 'EPS' and 'X' as a variables. You can now set the accuracy for the integration and solve for 'X'. The result appears within seconds.

STEQ

SOLVR

:)

I didn't try the ROOT command but it should work likewise.

Marcus

*Edited: 28 Feb 2008, 4:43 a.m. *