Resistance, again.
Rodger Rosenbaum
Joe Horn discussed ways to get better accuracy, and I also entered the
fray:
I happened to look at that thread again lately, and it occurred to me that
there is yet another way.
Imagine that you have you have 5 numbers: A,B,C,D and E.
You would like to calculate sums of the products of subsets of the numbers,
taken in all possible ways. In other words, you would like to calculate:
S1 = A + B + C + D + E
S2 = A*B + A*C + A*D + A*E + B*C + B*D + B*E + C*D + C*E + D*E
S3 = A*B*C + A*B*D + A*B*E + A*C*D + A*C*E+ A*D*E
B*C*D + B*C*E + B*D*E + B*D*E
S4 = A*B*C*D + A*B*C*E + A*B*D*E + A*C*D*E + B*C*D*E
S5 = A*B*C*D*E
I hope I got them all correct!
If you have more or fewer than 5 numbers, the extension should be obvious.
Well, Mirabile Dictu! There is a built-in function in the HP48G and its
descendants that will do this all at once with 15 digit internal precision,
returning the final result in 12 digit precision, of course.
You may only want one of these sums, or you may want several.
In the earlier thread, I expressed my surprise to learn that PILIST and
SIGMALIST don't do 15 digit internal arithmetic before returning a 12 digit
result.
As you can see above, S1 and S5 provide the sum and product of a bunch of
numbers with the arithmetic done in 15 digit precision.
The function is PCOEF. Just put your numbers in a vector like this:
[ A B C D E ]
(or however many you have), and execute PCOEF. Exact numbers are converted
to approximate before PCOEF does its work. You get back the various sums
(polynomial coefficients, with signs as needed to make the polynomial have
roots of the correct sign).
So, to put this to use, here is a little program, PRESZ.
<< DUP SIZE SWAP OBJ-> ->ARRY PCOEF SWAP GETI ROT ROT GET SWAP / NEG >>
Borrowing (and slightly editing) Joe Horn's description from the earlier
thread:
"Input: List of positive resistor values (or individual work times).
Output: Parallel resistance (or time working together).
Trick: If you want to know what resistor to add to a circuit to attain
a given total resistance, input the total resistance as a NEGATIVE; the
output will be the negative value of the needed resistor. (Illustrated
by examples 2 and 3 below).
Try inputs of { A B }, { A B C }, and { A B C D } for a visual
representation of the algorithm used here (not applicable to PRESZ). As
you'll see, it performs only ONE division. Hence its accuracy.
EXAMPLE 1: What is the total resistance of a 9 ohm, 136 ohm, and 153
ohm resistor wired in parallel?
{ 9. 136. 153. } PRESZ --> 8.
Notice the accuracy. It's exact, whereas INV SigmaLIST INV erroneously
returns 8.00000000006.
EXAMPLE 2: If you have two resistors in parallel, each 120 ohms, and
you want to add a third one in parallel with them such that the total
resistance becomes 44 ohms, what value resistor must you use?
Input the known resistors as positive values, and the total resistance
as negative:
{ 120. 120. -44. } PRESZ --> -165.
The third resistor must have a value of 165 ohms.
EXAMPLE 3: Bill can paint a house in 6 hours; Ted can do it in 10
hours. When they work together with Alice, they finish in 3 hours. How
long would it take Alice by herself?
Input the known times as positive values, and the total time working
together as negative:
{ 6 10 -3 } PRESZ --> -15.
It would take Alice 15 hours to paint the house by herself."
PRESZ gives better results for some of the exceptional cases given in the
Sept, 2006 thread.
I'm sure that the many readers of this group can think of applications
where they might want to calculate some of these sums of products.
Joe Horn
> ...
> Well, Mirabile Dictu! There is a built-in function in the HP48G and its
> descendants that will do this all at once with 15 digit internal precision,
> returning the final result in 12 digit precision, of course.
> The function is PCOEF. ...
Cool! Thanks for yet another way to do the "parallel resistor
problem" in User RPL!
Unfortunately, your PCOEF method is not *quite* as accurate as the
simple 15-digit precision method. ALL of the previously published or
posted User-RPL programs, including your new PRESZ program, get the
wrong answer for any of the following lists of inputs (don't change
the elements' order):
Example #1: { 6124. 1700. 8602. 6034. }
Exact answer --> 496660878175/513302414
Correctly rounded to 12 significant digits --> 967.579470949
All of the User RPL programs get the last digit wrong. For example,
your PRESZ program is one ULP too *low*.
Example #2: { 2808. 8850. 9487. 6824. }
Exact answer --> 4189643484975/3021020881
Correctly rounded to 12 significant digits --> 1386.83036298
All of the User RPL programs (including PRESZ) are one ULP too *high*.
Likewise:
Example #3: { 2682. 4143. 953. 7153. }
Example #4: { 7059. 2632. 4545. 2187. }
Example #5: { 4419. 6563. 2940. 3369. }
Also:
Example #6: { 192. 623. 915. 736. 186. }
Example #7: { 473. 582. 626. 253. 879. }
Example #8: { 824. 121. 987. 285. 568. }
Even this:
Example #9: { 53. 96. 73. 41. 27. 84. 98. }
These examples were obtained simply by generating numbers randomly and
looping until none of the User RPL programs got the right answer.
Such examples are not at all rare, and are quickly found. Notice,
however, that the simple System RPL program (which uses 15-digit
accuracy) gets the right answer for all of the above examples.
I'm afraid there's no fast way of doing it in User RPL that *always*
gets the answer correct to 12 significant digits... ASSUMING that the
inputs are ordinary reals, not algebraics or "integers" (TYPE 28), of
course. I know, Rodger, that you were making so such claim about
PRESZ, but it would have been massively cool if PRESZ were as accurate
as the System RPL program. *sigh* The whole subject is rendered
moot, of course, by the "exact mode" in most of HP's high-end models,
which I used to find the "exact answers" above.
For reference, here's the System RPL program (more accurate than
PRESZ) for the HP50g, with the first three commands being added to
coerce the inputs into reals. (Is there a faster way?)
----- PRESL (Input: *list* of numbers) -----
::
xAXL
xAXM
xAXL
CK1&Dispatch
BINT5
::
%%0
SWAP
DUPLENCOMP
#1+_ONE_DO
INDEX@
OVERSWAP
NTHCOMPDROP
%>%%1/
ROT
%%+
SWAPLOOP
DROP
%%1/
%%>%
;
;
BYTES (on assembled object in HP50g): #DD2Dh 66.5
-Joe-
Joe Horn
Oops, I meant to say "NO such claim". Sorry about the typo.
-Joe-
The Phantom
That's correct. Even if all the computations but one are done in
internal 15 digit arithmetic, that last division is done with 12 digit
reals, and an error can be made. PRESZ does that, and in addition, the
PCOEF method is much faster than my matrix method for a large number of
resistors.
>ASSUMING that the
>inputs are ordinary reals, not algebraics or "integers" (TYPE 28), of
>course. I know, Rodger, that you were making so such claim about
>PRESZ, but it would have been massively cool if PRESZ were as accurate
>as the System RPL program. *sigh* The whole subject is rendered
>moot, of course, by the "exact mode" in most of HP's high-end models,
>which I used to find the "exact answers" above.
>
>For reference, here's the System RPL program (more accurate than
>PRESZ) for the HP50g, with the first three commands being added to
>coerce the inputs into reals.
This method can make an error, too. For example, the list:
{87039 17111 86195 22040) should give an exact result of
7879.92927144940615 but doing it with 15 digit arithmetic on the HP50G
gives 7879.92927144945, an incorrect 15 digit result which would still
round to the correct 12 digit result.
But even using 15 digit arithmetic on the HP50G doesn't guarantee correct
12 digit results. (Remember that the 15 digit arithmetic doesn't round
correctly.) The list {11599 60411 80364 67092} when computed with exact
arithmetic gives 7685.45611722 as the final 12 digit result, but doing it
with the HP50G's 15 digit internal arithmetic and then rounding to a final
12 digit result gives 7685.45611723.
This list also gives different results for PRESZ and for my matrix method
from 2006. It's the only case where I've seen that happen. This is no
doubt due to the fact that the matrix method does two 12 digit divides.
Veli-Pekka Nousiainen
Is it possible to get the algorithm in UserRPL?
I want to try LongFloat Library on these
"Joe Horn" <joe...@holyjoe.net> wrote in message
news:1184146253.7...@z28g2000prd.googlegroups.com...
> Example #3: { 2682. 4143. 953. 7153. }
> Example #4: { 7059. 2632. 4545. 2187. }
> Example #5: { 4419. 6563. 2940. 3369. }
>
> Also:
> Example #6: { 192. 623. 915. 736. 186. }
> Example #7: { 473. 582. 626. 253. 879. }
> Example #8: { 824. 121. 987. 285. 568. }
>
> Even this:
> Example #9: { 53. 96. 73. 41. 27. 84. 98. }
Rodger Rosenbaum
<velipekka....@saunalahti.fi> wrote:
>Old post, but interesting
>Is it possible to get the algorithm in UserRPL?
I think what you want is Joe's post here:
Veli-Pekka Nousiainen
<< OBJ-> R->I 1 - 1 DUP ROT @ using integers, inserted R->
START PICK3 * OVER + UNROT * SWAP
NEXT FDIV >> @ inserted FDIV
"Rodger Rosenbaum" <nos...@aol.com> wrote in message
news:sjhuh4p3aht0go98q...@4ax.com...