The Museum of HP Calculators

HP Forum Archive 21

[ Return to Index | Top of Index ]

HP 34s solve f'(x)=0
Message #1 Posted by Richard Berler on 5 Oct 2013, 3:11 p.m.

I wanted to find the minimum of x^1/2.

I tried Fill sqrt y^x. RTN. Using solve the on board f'(x) for .1 to 1, I get a domain error. On the HP 35s, the Dieter program works like a champ. What am I doing wrong?

      
Re: HP 34s solve f'(x)=0
Message #2 Posted by Richard Berler on 5 Oct 2013, 3:12 p.m.,
in response to message #1 by Richard Berler

I mean x^sqrt(x)

      
Re: HP 34s solve f'(x)=0
Message #3 Posted by Paul Dale on 6 Oct 2013, 4:22 a.m.,
in response to message #1 by Richard Berler

The problem here is f'(x) samples from the function at a number of points around the given x value. By default the step size is 0.1 which means you end up with -.1-.1, which the 34S cannot deal with.

Define the [delta]X global label to set the step size yourself. See the manual entry for f'(x) for details. The [delta]X label isn't case sensitive.

- Pauli

            
Re: HP 34s solve f'(x)=0
Message #4 Posted by Nigel J Dowrick on 6 Oct 2013, 8:53 a.m.,
in response to message #3 by Paul Dale

...or you could put a test in your program for negative / zero values and return "1" when they are detected. This will slow things down slightly, but the WP-34S is fast!

Nigel (UK)

            
Re: HP 34s solve f'(x)=0
Message #5 Posted by Richard Berler on 6 Oct 2013, 12:27 p.m.,
in response to message #3 by Paul Dale

What puzzles me is that I use dx=.029....this seems to give better results on some problems than the default of .1 or some small dx such as 1E-06.

Still, using dx=.029, and using a tight interval for solve (1.2 to 1.4) for this function where f'(x) is real for x>0, and should equal 0 for x~1.353, why should this produce the domain error?

I clearly don't know how f'(x) is approximated on the 34s and/or how this works using solve to find f'(x)=0

                  
Re: HP 34s solve f'(x)=0
Message #6 Posted by Dieter on 6 Oct 2013, 4:44 p.m.,
in response to message #5 by Richard Berler

Quote:
...using a tight interval for solve (1.2 to 1.4) for this function where f'(x) is real for x>0, and should equal 0 for x~1.353
For f(x) = xsqrt(x) the first derivative is 1/2 xsqrt(x)-1/2 (2 + ln x).
Which is zero for x = e-2 = 0,135335.
And that's what my 35s program returns as well:
  Y001 LBL Y
  Y002 RCL X
  Y003 RCL X
  Y004 0,5
  Y005 y^x    ' use x^0,5 instead of sqrt(x)
  Y006 y^x
  Y007 RTN
 
  0,1 [ENTER] 1 [XEQ] E [ENTER]
  =>  SOLVING
      X = 0,1353
  {XEQ] F [ENTER]
  =>  F = 0,4791

Dieter

                        
Re: HP 34s solve f'(x)=0
Message #7 Posted by Richard Berler on 6 Oct 2013, 5:17 p.m.,
in response to message #6 by Dieter

I gave your program credit in my 1st post...indeed it worked great. I modified the program slightly so that I can then execute f(x) at that point, and have both values show simultaneously on the HP 35s 2 line display.

Still puzzled by the 34s since my dx is small (.029) and f'(x) is real all the way down to zero

                              
Re: HP 34s solve f'(x)=0
Message #8 Posted by Paul Dale on 6 Oct 2013, 5:49 p.m.,
in response to message #7 by Richard Berler

The 34S uses a ten point numerical derivative if it can. This means it will go five times .029 = .145 either side of the value the solver supplies. This is more than enough to bring the evaluation point negative on its own, however the solver will also attempt to bracket the root pushing it even further negative.

You could try setting flag D to allow not number and infinite results. The derivative code should fall back to lower order numerical derivatives if the function returns NaNs. I'm not sure what the solver will do, but there is some attempt to deal with things in there.

The source code for the solver and the derivative routines are in the trunk/xrom directory, if you want to investigate the internal behaviour further.

- Pauli

                              
Re: HP 34s solve f'(x)=0
Message #9 Posted by Dieter on 7 Oct 2013, 3:03 p.m.,
in response to message #7 by Richard Berler

Quote:
I gave your program credit in my 1st post...indeed it worked great.
Thank you very much. However, I basically wanted to point out that the local minimum is not located at x = 1,353 or somewhere between 1,3 and 1,4, as you wrote. Actually it is at x = 0,1353.

Quote:
Still puzzled by the 34s since my dx is small (.029) and f'(x) is real all the way down to zero
The 34s f'(x) command evaluates the user function at numerous points around x. Pauli mentioned an interval of x +/- 5 dx. With dx as large as 0,03 this means you will get significantly below zero.

I tried your function xsqrt(x) in the following way on the 34s. Two points are essential:

  1. Provide a decent value for dx. Values as small as x/100000 are fine here. I did it this way:
       LBL [delta]X
       X=0?
       INC X    ' for x=0, continue with x=1
       SDR 05   ' divide by 100000
       RSD 01   ' round to one significant digit
       RTN
    
  2. The f'(x) command returns an approximation (!) of the first derivative. How accurate may this estimate be? Six digits? Eight? Ten? More? We simply do not know. So we cannot expect a result of exactly zero at the local minimum or maximum. There is not much sense in having the solver going through half a dozen more iterations in order to find the 10th, 12th or 16th digit of a solution that is not that exact anyway. So it's a good idea to stop the solver as soon as the derivative drops below, say, 1E-9 or 1E-10. A simple round command will do that. The following code for the derivative rounds all results below 5E-10 to zero.
       LBL "FX"
       ENTER
       SQRT
       y^x
       RTN
     
       LBL "DER"
       f'(x) "FX"
       RDP 09     ' round to nine places
       X<>0?      ' if not equal to zero,
       X<> L      ' restore unrounded result
       RTN
    
This way everything works on the 34s as well:
   0,1 ENTER 1   SLV "DER"
   =>  0,13533528322
This agrees in 10 digits with the true result.

Addendum: unlike simple implementations, the 34s multi-point derivative seems to handle large dx values very well. In the above code, replace SDR 05 with SDR 02, and RDP 09 may become RDP 12. For the same initial guesses, the solver should now return a result with 14 valid decimals.

Dieter

Edited: 8 Oct 2013, 4:20 p.m.


[ Return to Index | Top of Index ]

Go back to the main exhibit hall