http://groups.google.com/group/comp.sys.hp48/browse_frm/thread/aabdab...

Then in 2007 I picked up the topic again:

http://groups.google.com/group/comp.sys.hp48/browse_thread/thread/2d4...

Now I think I've come up with a way to cause all of the computations to be done
with 15 digit arithmetic with only user RPL commands.

The idea is to start with a list of resistor values such as:

{ 6124. 1700. 8602. 6034.}

and convert it to a 1x1 matrix containing the resistor values as an explicit sum
of reciprocals.  In other words, the above list should become:

[[ 1./6124.+1./1700.+1./8602.+1./6034 ]]

Then invert the matrix by pressing the 1/x key.  On the HP48G series, and its
descendants the HP49G+ and HP50G, all of the arithmetic appears to be done with
15 digits.

The examples Joe Horn gave that failed on all the previous user RPL programs:

{ 6124. 1700. 8602. 6034.}

{ 2808. 8850. 9487. 6824.}

give the correct result with this method.

The example I gave, {11599 60411 80364 67092}, that fails with 15 digit
arithmetic, still fails with this new scheme, as expected.

I invite the reader(s) to come up with a program to make the conversion from a
list of values to a 1x1 matrix of a sum of the reciprocals of those values.

Note that I don't think this will work on a 48S/SX (needs the G/GX
list processing features).

With exact mode, the program << INV \GSLIST INV >> gives the desired final
result for parallel resistors (one might want a final EVAL in there).

I'm looking for a way to do it if the starting numbers are approximate, and the
calc is in approximate mode.

If you're starting with { 2. 3. }, for example, the first INV in your program
will give { .5 .333333333333 }, and you're dead in the water.

Brilliant idea for HP49/50!

{ 6124. 1700. 8602. 6034. }

\<< 1. \<< 1. SWAP ::/ DTAG
IF NSUB 1. > THEN ::+ DTAG END \>>
DOSUBS \->ALG INV \->NUM \>>

{ 6124. 1700. 8602. 6034. }

\<< 1. \<< 1. SWAP ::/ DTAG
IF NSUB 1. > THEN ::+ DTAG END \>>
DOSUBS \->ALG { 1. 1. } \->ARRY INV ARRY\-> DROP \>>

That's what I was thinking of when I said HP48G.  It's been so long since I've
played with my HP48G that I was thinking that an object like [[ ' 1./5.' ]]
wouldn't be symbolic since it doesn't have any literal variables. :-(

However, this is not so.  You're right, you can't have algebraics in matrices on
the HP48G.

So my new scheme only works for the HP49 and after.

BTW, I noticed while playing around with all this that the fraction:

29782376044851960
-----------------
  3779523269677

which is the exact solution for these resistor values:

{ 87039 17111 86195 22040 }

doesn't evaluate to a properly rounded 12 digit floating point number after
executing ->NUM.]

Has it been known before that ->NUM doesn't always round properly?

It appears that it converts the numerator and denominator separately to floating
point and then divides.  This is interesting, because it means that just using
the exact arithmetic capability of the HP49/50 to get a rational exact solution
and then converting it to a 12 digit floating point number with ->NUM won't give
as good a result as my matrix scheme for { 87039 17111 86195 22040 }.

Although you note that numeric matrix operations, in 48G/49G/50G series,
are carried out with "long real" precision, what about during
evaluation of symbolic expressions?

What, then, when operating with a "matrix" whose element(s)
are themselves symbolic expressions?

'29782376044851960/3779523269677' \->NUM @ 7879.92927146

[[ '29782376044851960/3779523269677' ]] \->NUM @ [[ 7879.92927146 ]]

The desired result is 7879.92927145, so no joy thus far.

Continuing with some other simple experiments:

[[ '1./7.' ]] INV @ [[ 7. ]]

Since '1./7.' INV already produces 7.
this is not yet remarkable.

[[ '0.+1./7.' ]] INV @ [[ 7. ]]

This last example is a bit more remarkable, since:

'0.+1./7.' \->NUM @ 0.142857142857 @ INV @ 7.00000000001

'0.+1./7.' INV @ '1/(0.+1./7.)' @ \->NUM @ 7.00000000001

Placing the symbolic within a matrix, then performing a function,
but without ever using \->NUM,
seems to have somehow improved the numerical accuracy,
even though all numerics in the input were reals!

[[ '0+3779523269677/29782376044851960' ]] INV @ [[ '29782376044851960/3779523269677' ]]

Oh well -- I must leave it to someone with more time,
to figure out how to more accurately evaluate '29782376044851960/3779523269677'

Note that many of you have one extra hour to complete that task tonight!

<< DUP PILIST OVER DUP / OVER * ROT / SIGMALIST / >>

I came up with a similar program that's slightly smaller:
<< DUP PILIST DUP ROT / SIGMALIST / >>

The results are still no better however.