HP35s  solving functions in user programs  Hewlett Packard
This is a discussion on HP35s  solving functions in user programs  Hewlett Packard ; Hi all,
the HP35s offers the wellknown HP Solve function which can be used
with equations (solving for one of several variables) as well as with
userprogrammed routines. In this case Solve returns a zero of this
programmed function.
In ...

HP35s  solving functions in user programs
Hi all,
the HP35s offers the wellknown HP Solve function which can be used
with equations (solving for one of several variables) as well as with
userprogrammed routines. In this case Solve returns a zero of this
programmed function.
In the days of the good old HP34C (first model offering HP Solve and
Integrate) Solve could be used for any program, even complex ones with
loops and iterations. Also Solve and Integrate could be combined, which
is no longer possible today. While this limitation is well documented, I
wonder why the HP35s cannot solve certain user routines just as the 34C
did  the calculator seems to get stuck in an endless loop, sometimes
ending in a final "NO ROOT FND".
Example:
x * (1/3 + 1/2 + 1/1)  2 = 0
Solution is x = 12/11 = 1.0909...
Direct method:
R001 LBL R
R002 3
R003 1/x
R004 2
R005 1/x
R006 +
R007 1
R008 1/x
R009 +
R010 RCL X
R011 *
R012 2
R013 
R014 RTN
FN= R ; solve the function at label R
0 STO X 2 ; provide two initial guesses
SOLVE X
=> SOLVING
X= 1.0909 ; Solve returns correct result
Okay, that was easy.
Now try the same function with a loop inside:
R001 LBL R
R002 3
R003 STO A
R004 0
R005 RCL A
R006 1/x
R007 +
R008 DSE A ; A := A1, still > 0 ?
R009 GTO R005
R010 RCL X
R011 *
R012 2
R013 
R014 RTN
FN= R ; solve the function at label R
0 STO X 2 ; provide two initial guesses
SOLVE X
=> SOLVING ...
The 35s gets stuck in an infinite loop. After a few minutes of staring
at the display, pressing C cancels the process.
Question: what happens here? There seems to be an issue either with
backward jumps and/or changes of variables inside the user routine.
What *exactly* is the problem here? Is this behavior documented
somewhere? The manual didn't provide any hints.
Dieter

Re: HP35s  solving functions in user programs
On Jul 31, 1:48*pm, Dieter wrote:
> Hi all,
> Now try the same function with a loop inside:
>
> R001 LBL R
> R002 3
> R003 STO A
> R004 0
> R005 RCL A
> R006 1/x
> R007 +
> R008 DSE A * * *; A := A1, still > 0 ?
> R009 GTO R005
> R010 RCL X
> R011 *
> R012 2
> R013 
> R014 RTN
>
> FN= R * * * * *; solve the function at label R
> 0 *STO X *2 * *; provide two initial guesses
> SOLVE X
>
> => SOLVING ...
>
> The 35s gets stuck in an infinite loop.
I don't have an HP35s, but my 32SII uses much the same programming,
and your program worked okay for me, returning 1.0909. One difference
is that the 32 doesn't allow jumping to line numbers, only LBLs, so I
had to insert LBL B ahead of R005 and replace R009 with GTO B.
Maybe it's something unique to the 35s.
Bill

Re: HP35s  solving functions in user programs
On 31 jul, 19:48, Dieter wrote:
> Hi all,
>
> the HP35s offers the wellknown HP Solve function which can be used
> with equations (solving for one of several variables) as well as with
> userprogrammed routines. In this case Solve returns a zero of this
> programmed function.
>
> In the days of the good old HP34C (first model offering HP Solve and
> Integrate) Solve could be used for any program, even complex ones with
> loops and iterations. Also Solve and Integrate could be combined, which
> is no longer possible today. While this limitation is well documented, I
> wonder why the HP35s cannot solve certain user routines just as the 34C
> did  the calculator seems to get stuck in an endless loop, sometimes
> ending in a final "NO ROOT FND".
>
> Example:
>
> x * (1/3 + 1/2 + 1/1)  2 *= *0
> Solution is x = 12/11 = 1.0909...
>
> Direct method:
>
> R001 LBL R
> R002 3
> R003 1/x
> R004 2
> R005 1/x
> R006 +
> R007 1
> R008 1/x
> R009 +
> R010 RCL X
> R011 *
> R012 2
> R013 
> R014 RTN
>
> FN= R * * * * *; solve the function at label R
> 0 *STO X *2 * *; provide two initial guesses
> SOLVE X
>
> => SOLVING
> * *X= 1.0909 * ; Solve returns correct result
>
> Okay, that was easy.
> Now try the same function with a loop inside:
>
> R001 LBL R
> R002 3
> R003 STO A
> R004 0
> R005 RCL A
> R006 1/x
> R007 +
> R008 DSE A * * *; A := A1, still > 0 ?
> R009 GTO R005
> R010 RCL X
> R011 *
> R012 2
> R013 
> R014 RTN
>
> FN= R * * * * *; solve the function at label R
> 0 *STO X *2 * *; provide two initial guesses
> SOLVE X
>
> => SOLVING ...
>
> The 35s gets stuck in an infinite loop. After a few minutes of staring
> at the display, pressing C cancels the process.
>
> Question: what happens here? There seems to be an issue either with
> backward jumps and/or changes of variables inside the user routine.
> What *exactly* is the problem here? Is this behavior documented
> somewhere? The manual didn't provide any hints.
>
> Dieter
Hello Dieter,
Have a look at
http://www.hpmuseum.org/cgisys/cgiw...s.cgi?read=896
for a program that works.
Note that I have had my share of infinite loops while programming the
HP35s... (no fun)
Caspar

Re: HP35s  solving functions in user programs
On Jul 31, 10:48*am, Dieter wrote:
> Hi all,
>
> the HP35s offers the wellknown HP Solve function which can be used
> with equations (solving for one of several variables) as well as with
> userprogrammed routines. In this case Solve returns a zero of this
> programmed function.
>
> In the days of the good old HP34C (first model offering HP Solve and
> Integrate) Solve could be used for any program, even complex ones with
> loops and iterations. Also Solve and Integrate could be combined, which
> is no longer possible today. While this limitation is well documented, I
> wonder why the HP35s cannot solve certain user routines just as the 34C
> did  the calculator seems to get stuck in an endless loop, sometimes
> ending in a final "NO ROOT FND".
>
> Example:
>
> x * (1/3 + 1/2 + 1/1)  2 *= *0
> Solution is x = 12/11 = 1.0909...
>
> Direct method:
>
> R001 LBL R
> R002 3
> R003 1/x
> R004 2
> R005 1/x
> R006 +
> R007 1
> R008 1/x
> R009 +
> R010 RCL X
> R011 *
> R012 2
> R013 
> R014 RTN
>
> FN= R * * * * *; solve the function at label R
> 0 *STO X *2 * *; provide two initial guesses
> SOLVE X
>
> => SOLVING
> * *X= 1.0909 * ; Solve returns correct result
>
> Okay, that was easy.
> Now try the same function with a loop inside:
>
> R001 LBL R
> R002 3
> R003 STO A
> R004 0
> R005 RCL A
> R006 1/x
> R007 +
> R008 DSE A * * *; A := A1, still > 0 ?
> R009 GTO R005
> R010 RCL X
> R011 *
> R012 2
> R013 
> R014 RTN
>
> FN= R * * * * *; solve the function at label R
> 0 *STO X *2 * *; provide two initial guesses
> SOLVE X
>
> => SOLVING ...
>
> The 35s gets stuck in an infinite loop. After a few minutes of staring
> at the display, pressing C cancels the process.
>
> Question: what happens here? There seems to be an issue either with
> backward jumps and/or changes of variables inside the user routine.
> What *exactly* is the problem here? Is this behavior documented
> somewhere? The manual didn't provide any hints.
>
> Dieter
Have you tried stepping through the program?

Re: HP35s  solving functions in user programs
cappy2112 wrote:
> [ I wrote ]
> ...
> > R001 LBL R
> > R002 3
> > R003 STO A
> > R004 0
> > R005 RCL A
> > R006 1/x
> > R007 +
> > R008 DSE A * * *; A := A1, still > 0 ?
> > R009 GTO R005
> > R010 RCL X
> > R011 *
> > R012 2
> > R013 
> > R014 RTN
> >
> > FN= R * * * * *; solve the function at label R
> > 0 *STO X *2 * *; provide two initial guesses
> > SOLVE X
> >
> > => SOLVING ...
> >
> > The 35s gets stuck in an infinite loop. After a few minutes of staring
> > at the display, pressing C cancels the process.
....
> Have you tried stepping through the program?
Yes, shure.
The *program* is perfectly okay and returns the expected values:
1 STO X
XEQ T => 0,1667
2 STO X
XEQ T => 1,1667
12/11 STO X
XEQ T => 0,0000
So, everything's fine so far.
As long as you don't start Solve. <8)
If Solve is interrupted and you try to SST trough the very same program,
weird things happen: the individual program steps appear as usual and it
looks as if they were exectued, but the stack does not change at all: it
shows the two initial guesses (RegT=1, RegZ=2) and 2 in RegY and RegX.
Even the variable A in the example doesn't change its value altough it
should be decremented until it becomes zero (DSE A, line R008). I think
that's exactly the reason why the 35s gets stuck  the DSEloop doesn't
terminate.
There seems to be a problem with that variable A inside the loop. Some
more testing showed that the program actually stores *no value at all*
in A! I tried Pi STO A. After starting Solve and waiting for a few
seconds (i.e. the routine should have overwritten A with the value 3 in
R002 at least once as the routine was executed for the first time)
a VIEW A still shows the old presolve value: A = 3,1416.
Completely confused 
Dieter

Re: HP35s  solving functions in user programs
Bill Markwick wrote
> I don't have an HP35s, but my 32SII uses much the same programming,
> and your program worked okay for me, returning 1.0909.
That's nice  but the 32S/SII and 35S are different in several ways. 8)
> One difference
> is that the 32 doesn't allow jumping to line numbers, only LBLs, so I
> had to insert LBL B ahead of R005 and replace R009 with GTO B.
Tried that as well: replaced lineaddressing by labeladdressing.
Same result. See my other posts in this thread.
> Maybe it's something unique to the 35s.
Yes... "unique"  I think that's the word. <8)
Dieter

Re: HP35s  solving functions in user programs
caslugt@gmail.com wrote:
> Have a look at
> http://www.hpmuseum.org/cgisys/cgiw...s.cgi?read=896
> for a program that works.
Yes, thank you. Reminds me of the good old days when I wrote similar
programs for my HP41. <8)
Is there a special reason why you didn't use DSE or ISG where the
advantage would be obvious?
> Note that I have had my share of infinite loops while programming the
> HP35s... (no fun)
Must be another thread on hpmuseum.org  or were these problems not
discussed there? At the moment I only remember some guy who had problems
with programs that could not be interrrupted at all.
Dieter

Re: HP35s  solving functions in user programs
On 11 aug, 17:03, Dieter wrote:
> Is there a special reason why you didn't use DSE or ISG where the
> advantage would be obvious?
Not really, I am not that familiar with the HP35S yet, I will look
into it. Thanks.
> > Note that I have had my share of infinite loops while programming the
> > HP35s... (no fun)
>
> Must be another thread on hpmuseum.org  or were these problems not
> discussed there? At the moment I only remember some guy who had problems
> with programs that could not be interrrupted at all.
I had the same problem, the ON key or the R/S key did not work...
paperclip reset and all my hard work typing all these lines was lost
(a couple of times)... :(
Caspar

Re: HP35s  solving functions in user programs
"Dieter" wrote in message
news:urk0a4pmqv2fgg822pndt5uqt4e8p0eg2s@4ax.com...
> Completely confused 
The 35s has known bugs that are similar to this  expressions that reference
memory variables instead get values coming from the stack, for instance.
(This is bug #15 at
http://www.hpmuseum.org/cgisys/cgiw...s.cgi?read=735 , and
there was a forum discussion where some guy figured out exactly what gets
substituted where during evaluation.)
HP has been informed of these problems and had shown zero public interest in
fixing any of them. :(
Joel