ram@tellabs.com (Bob Martin) (10/12/90)
I was playing around with some equations and learning about ISOL, when I ran across the following situation: 2: 'PV=PMT*((1-(1+INTPP)^-NUMP)/INTPP)' 1: 'NUMP' execute ISOL I expect: 1: 'NUMP=-(LN(1-PV/PMT*INTPP)/LN(1+INTPP))' but I get: 1: 'NUMP=-((LN(1-PV/PMT*INTPP)+2*pi*i*n1)/LN(1+INTPP))' Now, I get confused by the "2*pi*i*n1" term, so I diligently search the manual for an explanation. On pg. 393 I find out about general and principal solutions and how flag -1 affects this. Fine. I also learn what n1 is - an arbitrary integer. Now the paragraph below that states that when I set flag -1 to get principal solutions, n1 will be set to zero (hence removing that term). So instead of redoing the ISOL with -1 set, I go into SOLVR anyway, and set n1 = 0. When I solve for NUMP (having supplied sane values for PV, INTPP, and PMT), I get an error - "Bad guess(es)". ???? What's going on? So I edit the equation to remove the "+2*pi*i*n1" term, go back into SOLVR and recalculate, and everything works fine. So now I surmise that the 48 has a problem evaluating 2*pi*i*0. To check this, I enter '2*pi*i*n1' into the stack. I store 0 in n1 and hit EVAL, and I get ...... 0! I try storing 1 in n1 and EVAL .... '2*pi*i'!! So what in the world is going on here? Please help, I am very confused! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Bob Martin | ram@tellabs.com ...!uunet!tellab5!ram Tellabs, Inc. | "Listen to me now, and believe me later" Lisle, IL. 60532 | - Hans und Franz -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Bob Martin | ram@tellabs.com ...!uunet!tellab5!ram Tellabs, Inc. | "Listen to me now, and believe me later" Lisle, IL. 60532 | - Hans und Franz
edp@jareth.enet.dec.com (Eric Postpischil (Always mount a scratch monkey.)) (10/12/90)
In article <4155@tellab5.tellabs.com>, ram@tellabs.com (Bob Martin) writes: >When I solve for NUMP (having supplied sane values for PV, INTPP, and PMT), >I get an error - "Bad guess(es)". ???? What's going on? So I edit the >equation to remove the "+2*pi*i*n1" term, go back into SOLVR and recalculate, >and everything works fine. When the solver evaluates your expression, it temporarily forces numerical-evaluation mode. In evaluating the expression '2*pi*i*n1', the complex number (0,1) is used for 'i'. Even though n1 is 0, the result returned is the complex number (0,0) rather than the real number 0. As a result, the solver gets back a complex number for the whole expression. It doesn't like that. I tested this conjecture by changing 'i' to 'I' and setting it to 1; the solver was happy. -- edp
mr87625@tut.fi (Matti Rintala) (10/12/90)
On 11 Oct 90 22:56:48 GMT,
ram@tellabs.com (Bob Martin) said:
...
-> I get: 1: 'NUMP=-((LN(1-PV/PMT*INTPP)+2*pi*i*n1)/LN(1+INTPP))'
...
-> I go into SOLVR anyway, and set n1 = 0.
-> When I solve for NUMP (having supplied sane values for PV, INTPP, and PMT),
-> I get an error - "Bad guess(es)". ???? What's going on? So I edit the
-> equation to remove the "+2*pi*i*n1" term, go back into SOLVR and recalculate,
-> and everything works fine. So now I surmise that the 48 has a problem
-> evaluating 2*pi*i*0. To check this, I enter '2*pi*i*n1' into the stack.
-> I store 0 in n1 and hit EVAL, and I get ...... 0! I try storing 1 in n1 and
-> EVAL .... '2*pi*i'!! So what in the world is going on here?
Well, actually it's quite interesting, but logical:
When you EVAL '2*pi*i*n' with n=0, you get 0 because the calculation
is done SYMBOLICALLY (i.e. 'i' is just a symbolic constant, and
anything times 0 is 0). When you use SOLVR to find the answer, it
automatically switches to Numeric Results mode (because it solves
equations numerically). In this mode, EVALuating '2*pi*i*n' with n=0
is equal to '2*3.141...*(0,1)*0'. Because this expression has a
complex number in it, its result is also complex, i.e. (0,0), but NOT
0 (you can check this by setting the Numeric Results flag (-3) and
EVALuating the expression). Because SOLVR only works with real
numbers, it tells you 'Bad Guesse(s)' because it can't find any value
for n so that '2*pi*i*n' would be real.
So, there's no bug in your HP. You just shouldn't use SOLVR for
equations with complex numbers in them (even when the complex number
is (0,0) ).
-> Bob Martin | ram@tellabs.com ...!uunet!tellab5!ram
--
'I'm a personality prototype. You can tell, can't you?'
(Marvin the Paranoid Android)
*****************************************************************************
Matti Rintala mr87625@tut.fijohn@solvint.UUCP (10/13/90)
In article <4155@tellab5.tellabs.com> ram@tellabs.com (Bob Martin) writes: >I was playing around with some equations and learning about ISOL, when I ran >across the following situation: > >2: 'PV=PMT*((1-(1+INTPP)^-NUMP)/INTPP)' >1: 'NUMP' >execute ISOL >I expect: 1: 'NUMP=-(LN(1-PV/PMT*INTPP)/LN(1+INTPP))' >but I get: 1: 'NUMP=-((LN(1-PV/PMT*INTPP)+2*pi*i*n1)/LN(1+INTPP))' [ description of excursion into principle value solutions and arbitrary integers deleted] >When I solve for NUMP (having supplied sane values for PV, INTPP, and PMT), >I get an error - "Bad guess(es)". ???? What's going on? [ demonstrates that 2*\pi*i*n1 term is not the culprit ] > ... So what in the world is going on here? >Please help, I am very confused! Surprise, you've used bad guesses. Either set 'n1' to 0 or set the principle value flag, that's not your problem. Look at the equation returned by ISOL. The numerator of the left-hand side contains the term LN(1-PV/PMT*INTPP). Using ``reasonable '' values for PV, PMT and INTPP like 25000, 400, and 0.13 produces LN(-7.125), which produces a complex result that the 48 assumes is the result of bad initial guesses for the unknown. The problem is that --- in this case --- the value for INTPP is 12 times too high. 0.13 (13%) is the ANNUAL interest rate and not the periodic interest rate (INTPP=interest per period). Divide this by 12 and get 0.01833, use this in the expression (you then have LN(0.3229)) and get 104.9 for the number of periods (months). That's 8 3/4 years. If you've not made a mistake in scaling your interest rate, you may be following the wrong sign convention. Your original formula requires that PV and PMT both be the same sign, + or -. All of the newer HP calculators (including the 48 in the Equation Library Card) require that the signs of these two be opposite to signify the direction of cash flow --- one is to you and the other is from you. Using the wrong convention can cause the LN of a negative number and give you the same error. You may already know this, but you don't need to ISOLate NUMP before SOLVing for it. The SOLVEr will solve for any unknown in any location in the equation/expression. I just used SOLVE on the original equation and got the same answer for NUMP. Finally, most problems I've seen with the 48 are USERS either not understanding how to use the calculator or some aspect of mathematics, or problem solving in general. The ``bugs'' in the 48 are remarkably few and Hewlett-Packard should be rightly praised for its product. On the other hand, indiscriminate use of the term ``bug'' in all confusing situations paints HP in a bad light for those who are either novices with or don't own 48's. Uncool. Please be sure of your facts before you use the `b' word, and even then, bugs are best reported directly to HP where there's a MUCH better chance that they will get appropriate attention. Announcing the resolution of your problem to the network would be much appreciated, though. I don't mean to discourage questions like this one, just to discourage casual slander. I hope I've helped, -- John W. Loux | Solve and Integrate Corp solvint!john@orstcs.cs.orst.edu | PO Box 1928 john@solvint.uucp | Corvallis, OR 97339-1928 | (503) 754-1207
john@solvint.UUCP (10/16/90)
I'm sorry and must apologize for my previous response to the person with the
problem concerning ISOL, SOLVE and terms concerning 'i'. I misread part of his
problem and thus gave a response based on poor assumptions.
Another poster suggested that the fact that 'i' in the equation causes the
evaluation to return (0,0) rather than 0 makes the 48 think that is has been
given bad guesses is much closer to the truth I suspect.
Again, I am appropriately abashed at my mis-analysis and am sorry.
--
John W. Loux | Solve and Integrate Corp
solvint!john@orstcs.cs.orst.edu | PO Box 1928
john@solvint.uucp | Corvallis, OR 97339-1928
| (503) 754-1207