Using FROOT recursively on the HP-71?

[Ángel Martin]

Folks, do you know of any programs using FROOT on the HP71 to recursively solve a system of 2 non-linear equations?

What would be the approach for such, given that the convergence will require both variables to iterate interdependently - i.e. not in separate stages?

Cheers,
ÁM

[Valentin Albillo]

.
Hola, Ángel:

(02-03-2017 02:07 PM)Ángel Martin Wrote:  Folks, do you know of any programs using FROOT on the HP71 to recursively solve a system of 2 non-linear equations?

In my article "HP-71B-MathROM-BakersDozen-Vol 2.pdf" which you surely have I mention two distinct approaches and include both short code snippets and examples.

The approach can be easily extended to handle systems of up to 5 non-linear equations (or linear for that matter).

Best regards.
V.
.

[Ángel Martin]

Thanks much Valentín, I'll dig it up from my files later tonight - straight from the master himself :-)

I'm hoping to learn enough to apply it on the 41, using the same buffer relocation tricks already put to work with INTEG for double integrals. I have the feeling it should be possible, albeit obviously much slower.

Will post anything worthwhile I find.

All the best,
Ángel

[Ángel Martin]

Well, it's resisting the first attempts - I guess it'll require more finesse than what I was trying so far...

One question though - I'm not sure I understand the syntax of the FNROOT used as a function of a continuous variable. I assumed FNROOT will return just *one* value (the first root found within the interval), but what does FVAR mean in the statement below:

DEF FNF = X*X+Y*Y <or whatever your function is>
DEF FNY (X) = FNROOT (Y1, Y2, FNF (X, FVAR ) )

Unfortunately I don't have the Math Pack manual, and neither can I figure it out (aging brain, no doubt).

Cheers,
ÁM

[Sylvain Cote]

(02-04-2017 01:16 PM)Ángel Martin Wrote:  Unfortunately I don't have the Math Pack manual, and neither can I figure it out (aging brain, no doubt).

Check your eMails.

[Valentin Albillo]

.
Hi again, Àngel:

(02-04-2017 01:16 PM)Ángel Martin Wrote:  I assumed FNROOT will return just *one* value (the first root found within the interval), but what does FVAR mean in the statement below:

DEF FNF = X*X+Y*Y <or whatever your function is>
DEF FNY (X) = FNROOT (Y1, Y2, FNF (X, FVAR ) )

Did you read the PDF article of mine I mentioned ? The first line of code you include above does not appear in any of the two examples in my article and in fact it's wrong, you'd need two user-defined functions, FNF(X,Y) and FNG(X,y) (not just a parameterless one), like this:

10 DEF FNF(X,Y)=f(x,y)
20 DEF FNG(X,Y)=g(x,y)

your single FNF above isn't sufficient and further, it lacks the X,Y parameters. Also, as seen in both my examples, you need a second FNROOT which calls the nested FNROOT in your second line above which is taken from my second example.

FVAR is to FNROOT as IVAR is to INTEGRAL, i.e., the variable you're solving for (integrating). In other words, it stands for the unknown being solved for (the "x" in "x^2-2=0", so to say).

I'd suggest you key-in any or both of my examples, run them to see how they work, and if needed do include some PRINT or DISP debugging statements to see how the variables are converging on the final X,Y solutions. This will probably help a lot.

Best regards.
V.

[Ángel Martin]

(02-04-2017 10:01 PM)Valentin Albillo Wrote:  .
Hi again, Àngel:

(02-04-2017 01:16 PM)Ángel Martin Wrote:  I assumed FNROOT will return just *one* value (the first root found within the interval), but what does FVAR mean in the statement below:

DEF FNF = X*X+Y*Y <or whatever your function is>
DEF FNY (X) = FNROOT (Y1, Y2, FNF (X, FVAR ) )

Did you read the PDF article of mine I mentioned ? The first line of code you include above does not appear in any of the two examples in my article and in fact it's wrong, you'd need two user-defined functions, FNF(X,Y) and FNG(X,y) (not just a parameterless one), like this:

10 DEF FNF(X,Y)=f(x,y)
20 DEF FNG(X,Y)=g(x,y)

your single FNF above isn't sufficient and further, it lacks the X,Y parameters. Also, as seen in both my examples, you need a second FNROOT which calls the nested FNROOT in your second line above which is taken from my second example.

FVAR is to FNROOT as IVAR is to INTEGRAL, i.e., the variable you're solving for (integrating). In other words, it stands for the unknown being solved for (the "x" in "x^2-2=0", so to say).

I'd suggest you key-in any or both of my examples, run them to see how they work, and if needed do include some PRINT or DISP debugging statements to see how the variables are converging on the final X,Y solutions. This will probably help a lot.

Best regards.
V.

Hi Valentín,

Yes I read your articles. Your code works just great, which I of course never doubted it wouldn't. And certainly the first line is lacking the variables in the definition and is not taken from your article - it was my futile attempt to short-cut the description of the issue in this post - "my bad", as they say nowadays.

My idea to apply the method to the 41's case is proving not to be very likely to work, for a couple of reasons. First off, thanks to Sylvain I got hold of the FROOT description and the "FVAR" syntax is clear to me - as you also put in your reply above it defines which variable is used in the solving. Right there there's a fundamental difference with the 41's version of SOLVE, which obviously can only deal with one variable.

I'm using the second template in your article - not the one based on the sum of the squares of both functions. If I understand it correctly it first obtains a root for Y (say "yr") using the second equation within [y1, y2] - thus with X constant. Then that yr is kept fixed and the first equation is used to solve for X within the interval [x1, x2]. The beauty is that for each X guess first the Yr root is obtained, and then Xr is attempted - repeating it so until both exist. So it's a sequential application, not a simultaneous one moving the (x,y) point. I think I get it.


Besides there's something funky that I need to troubleshoot. The buffer swapping idea works flawlessly with INTEG, so double integrals are calculated with a nested call to INTEG without a glitch. Yet for SOLVE I'm getting DUP BUF errors - it is as if the method called SOLVE three times instead of two; which makes no sense.

So back to the drawing board - let's see if at least I can conclude on the reason why it wouldn't work... Thanks again for your comments.

Best,
ÁM

[Ángel Martin]

Progress made at last - ignore the previous fumbling if you must, here's the real thing:

The key is how the functions are defined, whereby the first function forces repeated root searching of the second until both functions are satisfied. This needs to be translated to the 41 register-based memory scheme playing carefully with the definitions.

Let's use the same example from Valentin's article:
f(x,y) = x^2 + y^2 - 5
g(x,y) = x^2 - y^2 - 3

We'll use g(x,y) as the "slave" equation, and f(x,y) the "master" function - meaning that for each guess Xo we'll FIRST get the root Yo for g(Xo, y), and use that root as the companion guess "Yo" (never mind my colorful nomenclature). This we'll repeat until the pair (Xo, Yo) is a root for f as well as for g.

How to translate this to a FOCAL environment? Here we go...

1. The Function to solve for Xo is *not* f(x,y), but f(x, Yo) - now, this was all the time before my eyes in Valentin's article but took me a while to realize how to adapt it here; which is accomplished by carefully defining both f(x,y) and g(x,y)
2. The definition of g(x,y) must assume X constant in R00, whilst Y is given in the stack (per SOLVE's conventions). Then after the Yo root value is obtained, we need a call to f(x,Yo) within the nested function to "shape" it according to the master rule.
3. Thus it follows that the definition of f(x,y) should use X in R00 and Y in R01.
   

The code is shown below. The nested function LBL "*FG" is the secret sauce of the recipe:

Code:

01   LBL "FRT2"   LBL "FF"
02   CLKEYS       RCL 00
03   STO 05       X^2
04   RDN          RCL 01
05   STO 04       X^2
06   RDN          +
07   STO 03       5
08   RDN          -
09   STO 02       RTN
10   13           LBL "GG"
11   BUF?         STO 01
12   DELBUF       RCL 00
13   RCL 02       X^2
14   RCL 03       RCL 01
15   "*FG"        X^2
16   FROOT        -
17   RTN          3
18   LBL "*FG"    -
19   STO 00       END
20   14,013    
21   REIDBF    
22   RCL 04    
23   RCL 05    
24   "GG"    
25   FROOT    
26   13.014    
27   REIDBF    
28   RDN    
29   XEQ "FF"    
30   END

That's it, next step is the refining for a general-purpose case using routine names in ALPHA instead of hard-coded strings for LBL FF and LBL GG. Will post a proper article when it's ready to go - thanks again and sorry about the fumbling digressions ;-)

Best,
ÁM