Oh yes and I mean for any no. of variables.
Mick
Look into the use of lists.
Rp= INV SUM(List of parallel resistance vaues) INV
> Is there an easy way to generate a algebraic for say series
> and parallel resistance? Say: Ra+Rb+Rc or 1/Ra + 1/Rb + 1/Rc
> I looked at the summation function
That's for a series of terms expressed by a common formula,
not quite the case here.
Put N (number of resistors) on the stack and run:
@ Series:
\<< "" 1 ROT FOR n "+R" n R\->I + + NEXT
TAIL "'" SWAP + STR\-> STEQ 30 MENU \>>
@ Parallel:
\<< "" 1 ROT FOR n "+1/R" n R\->I + + NEXT
TAIL "'INV(" SWAP + STR\-> STEQ 30 MENU \>>
Type resistor values followed by each "Rn" menu key;
finally press "EXPR=" menu key for answer.
Best wishes from http://www.mum.edu
and http://www.maharishischooliowa.org
Could this be done (I am not near my HPs) by mapping 1/x to the list of
resistances, summing, and then 1/x?
> Could this be done (I am not near my HPs)
> by mapping 1/x to the list of resistances,
> summing, and then 1/x?
Yes, given a list of at least two resistances:
Series resistance: \GSLIST [SigmaLIST]
Parallel resistance: INV \GSLIST INV
For input { 2. 3. 6. }
the respective results are 11. and 1.
This has worked since model HP48G[X]
(the preceding "formula" version since HP48S[X])
"There is nothing new under the sun"
Ok I did a bit of research and came up with this:
<< depth -> N
<< 1 N
for N + 1
step
>>
>>
The only trouble is that it want to do more than the required number of
steps.
Mick Carey
OK I got two programs working, could someone check these and explain the
kludges I had to include?
@series
<< depth -> N
<< 2 N @why does this have to be 2 and not 1 say for a depth
for N + @three 1 -> 3 = 2, the number of additions????
next
>>
>>
@parrallel
<< depth -> N
<< 0 N
for N inv N roll
next inv n roll @why do I have to kluge the last run? Tryied
2 N @to do the loop again but it would not work?
for N +
next inv
>>
>>
The beauty of these routines is that you can enter Ra Rb and Rc into the
stack and get(for the second program) 1/(1/Ra+1/Rb+1/Rc)
then you can pull out subst and isol!!!
Cheers Mick Carey
http://tech.groups.yahoo.com/group/50g/
> @parallel
> << depth -> N
> << 0 N
> for N inv N roll ...
Do you want to use as input everything on the stack?
How about:
Series \<< DEPTH \->LIST \GSLIST \>>
Parallel \<< DEPTH \->LIST INV \GSLIST INV \>>
--
This isn't exactly what you're asking for, but someone might find it
helpful. I assign the following tiny program to my <RightShiftHold +>
key so that I can do resistor calculations on the fly.
<< INV SWAP INV SWAP + INV >>
(The second SWAP isn't necessary, just for style points if I'm using
symbolics.)
-wes
> This isn't exactly what you're asking for, but someone might find it
> helpful. I assign the following tiny program to my <RightShiftHold +>
> key so that I can do resistor calculations on the fly.
>
> << INV SWAP INV SWAP + INV >>
Less prone to roundoff error is this:
<< * LASTARG + / >>
Example: An input of 10 and 15 yields 5.99999999999 with the former
program and 6 with the latter.
If LASTARG is unacceptable, use this version instead:
<< DUP2 * UNROT + / >>
Extending this more-accurate algorithm to more than two inputs is left
as an exercise for the student. Hint: it's a rather simple loop.
-Joe-
The following is equivalent to << INV SigmaLIST INV >> except more
accurate:
PRESX by Joe Horn
Parallel Resistance, Extended accuracy
<< OBJ-> 1. - 1. DUP ROT
START PICK3 * OVER + UNROT * SWAP
NEXT / >>
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. 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. } PRESX --> 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. } PRESX --> -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 } PRESX --> -15.
It would take Alice 15 hours to paint the house by herself.
-Joe-
How about this:
Input is a list of resistances.
<< OBJ-> ->ARRY LASTARG DIAG-> DUP DET SWAP
OVER OVER IDN * SWAP / TRACE / >>
However, until I start using .0000000001% tolerance resistors, the
reciprocal of the sum of the reciprocals method will continue to work for
me!
> How about this:
>
> Input is a list of resistances.
>
> << OBJ-> ->ARRY LASTARG DIAG-> DUP DET SWAP
> OVER OVER IDN * SWAP / TRACE / >>
Fascinating! <said with one eyebrow raised> Slow, especially for lists
with many elements, but still fascinating. I wish I knew that much
about matrices! Next lifetime, maybe.
> However, until I start using .0000000001% tolerance resistors, the
> reciprocal of the sum of the reciprocals method will continue to work for
> me!
True! :-D
-Joe-
Input the list of reals { 8.8 8.8 } into all three programs (JH =
Joe Horn's program, OP = << INV SigmaLIST INV >>, and RR = Rodger
Rosenbaum's program) in EXACT MODE:
Outputs:
JH --> 4.4 (correct)
OP --> 4.40000000001 (bad)
RR --> 4.40000000003 (worse)
But change to APPROX MODE, and RR (with exactly the same real inputs)
yields the correct answer 4.4 exactly!
Strange, huh? Turns out that IDN returns an EXACT matrix of integer
objects when given an APPROX matrix (of reals) in EXACT mode. That
wrecks the accuracy of Rodger's program when it's run in approx mode.
I *think* that adding AXM immediately after IDN in his program fixes
the problem. So does clearing flag -105, but that's cheating. ;-)
-Joe-
What can I say but, "Arrrrggghh!"
It has been noticed in some postings over on the HP Museum forum that
matrix operations on matrices with mixed type 0 and type 28 numbers can
give unexpected results.
Ok, then, try this little routine:
PRESY, by Rodger Rosenbaum
<< DUP PILIST OVER DUP / OVER * ROT / SIGMALIST / >>
Create a 25 element list for testing like this, in exact mode:
5 HILBERT 2520 * ->NUM OBJ-> OBJ-> DROP * ->LIST
PRESX gives 20.1599999997
PRESY gives 20.16
My earlier matrix based program in approximate mode, with approximate
input, also gives (eventually) 20.16.
The exact answer is 20.16 (504/25); of course even PRESY will fail with a
big enough list of big enough numbers.
If ->NUM isn't used when creating the test list, so that the elements of
the list are exact integers, then PRESX (and PRESY) will get the exact
answer no matter how big the list (if the calc doesn't run out of memory).
> Create a 25 element list for testing like this, in exact mode:
> 5 HILBERT 2520 * ->NUM OBJ-> OBJ-> DROP * ->LIST
>
> PRESX gives 20.1599999997
> PRESY gives 20.16
Here's something funny. REVLIST your above-described list before
inputting it, and lo and behold:
PRESX gives 20.1600000001
PRESY gives 20.1599999999
For those who have never noticed it before, here's a way to see that
multiplication is NOT commutative in finite-state floating-point
machines:
2. sqrt 3. sqrt 5. sqrt * *
5. sqrt 3. sqrt 2. sqrt * *
--> should be the same but they're not.
This unfortunate phenomenon is what causes REVLIST to yield different
results above.
-Joe-
>Rodger Rosenbaum wrote:
>
>> Create a 25 element list for testing like this, in exact mode:
>> 5 HILBERT 2520 * ->NUM OBJ-> OBJ-> DROP * ->LIST
>>
>> PRESX gives 20.1599999997
>> PRESY gives 20.16
>
>Here's something funny. REVLIST your above-described list before
>inputting it, and lo and behold:
>
>PRESX gives 20.1600000001
>PRESY gives 20.1599999999
Non est mirabile dictu!
The reason I recast the program to use PILIST and SIGMALIST is because
for all these years I have believed that those functions did their work in
15 digit arithmetic and at the end, delivered a 12 digit result! I could
have sworn I checked that in years past.
Let hlist be the list derived from the 5 HILBERT bit. Now do this:
hlist PILIST, and get 4.89979795452E68; but the correct result is
4.8997979545115E68 (to 14 digits).
And if you do:
hlist REVLIST OBJ-> DROP, and then press the times key 24 times, you get
the same thing as hlist PILIST.
It appears that PILIST is only doing 12 digit arithmetic.
Now do this:
hlist OBJ-> 1 ->LIST ->ARRY 25 DIAG-> DET
and get 4.89979795451E68, the result of the 15 digit matrix operation.
Darn! That's too bad. It would be really nice if those list functions
did 15 digit arithmetic.
Huh?
X
> hlist OBJ-> 1 ->LIST ->ARRY 25 DIAG-> DET
> and get 4.89979795451E68, the result of the 15 digit matrix operation.
>
> Darn! That's too bad. It would be really nice if those list
> functions did 15 digit arithmetic.
Nice solution...
>Rodger Rosenbaum wrote:
>> On 26 Sep 2006 10:40:17 -0700, "Joe Horn" <joe...@holyjoe.net> wrote:
>>
>>> Rodger Rosenbaum wrote:
>>>
>>>> Create a 25 element list for testing like this, in exact mode:
>>>> 5 HILBERT 2520 * ->NUM OBJ-> OBJ-> DROP * ->LIST
>>>>
>>>> PRESX gives 20.1599999997
>>>> PRESY gives 20.16
>>>
>>> Here's something funny. REVLIST your above-described list before
>>> inputting it, and lo and behold:
>>>
>>> PRESX gives 20.1600000001
>>> PRESY gives 20.1599999999
>>
>> Non est mirabile dictu!
>
>Huh?
Ask Joe to explain it to you!