Resistance; once more into the breach.
Rodger Rosenbaum
Then in 2007 I picked up the topic again:
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.
The program I came up with is such a kluge that I'm ashamed to post it until I
see if somebody else can do a better job.
Dave
> 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.
>
> The program I came up with is such a kluge that I'm ashamed to post it until I
> see if somebody else can do a better job.
Here's a nice succinct implementation:
<< INV \GSLIST 1 ROW\-> 1 ROW\-> INV 1 GET >>
Note that I don't think this will work on a 48S/SX (needs the G/GX
list processing features).
-Dave
The Phantom
This works ok if the numbers in the starting list are exact integers, and the
calc is in exact mode.
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.
I want to end up with [[ 1./2.+1./3. ]]. The divisions associated with the
reciprocals mustn't happen until the matrix is inverted.
John H Meyers
> [[ '1./6124.+1./1700.+1./8602.+1./6034' ]] @ quotes added
>
> 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.
Do you mean HP49G, since HP48G[X] (and earlier)
do not have symbolic matrices?
Brilliant idea for HP49/50!
[r->] [OFF]
John H Meyers
{ 6124. 1700. 8602. 6034. }
\<< 1. \<< 1. SWAP ::/ DTAG
IF NSUB 1. > THEN ::+ DTAG END \>>
DOSUBS \->ALG INV \->NUM \>>
@ [r->] [OFF]
John H Meyers
{ 6124. 1700. 8602. 6034. }
\<< 1. \<< 1. SWAP ::/ DTAG
IF NSUB 1. > THEN ::+ DTAG END \>>
DOSUBS \->ALG { 1. 1. } \->ARRY INV ARRY\-> DROP \>>
@ [r->] [OFF]
Rodger Rosenbaum
wrote:
What the HP48G does that the the HP48S doesn't do, is to carry out matrix
arithmetic with all 15 digit arithmetic. Paul McClellan reworked the linear
algebra routines to achieve that result.
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 }.
John H Meyers
> 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.
I don't see how \->NUM could evaluate a general algebraic expression
without doing exactly that, since otherwise any intermediate results
could only be integers, although I suppose the actual issue
is that this conversion may be to ordinary reals,
rather than to "long" reals?
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!
[r->] [OFF]
Dave Hayden
<< 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.
Dave