f'(x) on WP-34S


I'm a bit puzzled by the results I'm getting using f'(x) on certain
functions. For example, if I use the following function:
LBL 77, 1/x, RTN
and perform f'(x) 77 with x having values of 0.2, 0.3, 0.4, or 0.5 I
get a +infinity error for each case. If I offset the values (e.g.,
4.9 or 5.1) I don't get the error message. For some reason (unknown
to me at least) it seems to sampling at x=0. If I understand the
manual correctly, it should be sampling at x+0.1 and x-0.1.



It samples at a number of points each spaced 0.1 apart.

It tried to use ten points -.5, -.4, -.3, -.2, -.1, .1, .2, .3, .4 and .5.

If you set flag D, the infinity error wouldn't be raised and the derivative should fall back to a four or six point estimate if the ten fails.

Alternatively, change the dX it is using by defining the appropriate global label.

- Pauli

Edited: 23 Apr 2012, 1:43 a.m. after one or more responses were posted


I updated the description of f'(x) in the manual to make it a bit clearer. Committed and ready for reading :-)


Pauli, can the effect of flag D be automated? From a user's point of view, the error is not justifiable because the function is well behaved at 0.5 and near it. Something like the following should do:

SF .00
FS? .00
But it might even be better to automate this all together for XROM code.

Edited: 23 Apr 2012, 2:44 a.m.


Yes, the D flag could be automated, yes I've considered this and decided not to do it. I think that only the derivatives will gain anything from this.

My reasoning is two fold:

  1. The actual error is being raised in the user's code -- xrom has no right to muck around with the user's settings while their code is executing. We've already gone to some degree of pain to ensure this.

  2. The derivative functions require some level of understanding as to what they are doing internally to be fully utilised. Making them automagically switch to a lower order estimate when a NaN or infinity is returned will only add to the understanding required. Hence, this behaviour requires the Danger flag to be set.

The first one is the big one to my mind, the user's settings are sacred. If they want to allow infinities and NaNs, there is a simple and well documented method to do so. Although, not all of the caveats and pitfalls are well documented :-)

However the second point is also quite relevant. Appropriately setting the dX value is important and requires some understanding of the function being differentiated.

- Pauli

PS: the original Gauss-Kronrod integrator also fell into the same category. The Romberg integrator doesn't.


"Alternatively, change the dX it is using by defining the appropriate global label."

Sorry to bother you with this question, but could you explain how to
properly do this. For example, I did this: LBL 'dx', 1EEX-3, RTN
(where d=delta) but this did not work so I'm doing something wrong.



Thomas, its not a 'd', its a 'delta' (to be found by f-EXIT (lower case), g-D (delta)).


Yes, that's what I meant to say (or write)and that's what I've been doing (without success).



Upper or lower case delta?

You need to put a lower case delta in. The case shift is f-shift EXIT. So the whole sequence is:

f-shift R/S ENTER^ f-shift EXIT g-shift STO ENTER

- Pauli


Yes, that's what I've been doing (using g-D not g-STO) and also using a lower case x. Should x be upper case?


Capital X.

XEQ'[delta]X' is the line of code that calls the user supplied function from XROM.

Sorry about giving the wrong delta key :-(
Teach me to type from memory :-(

- Pauli


The manual says lower case x -- so it is wrong :-) Well, it doesn't agree with the code.

- Pauli


When I define (small delta)X(uppercase x), then the f'(x) function
doesn't appear to work. For example, using LBL 'dX' (where d=small
delta), 1E-3, RTN and then apply f'(x) 77 to LBL 77, 1/x, RTN I get
no change in x on the stack.



Try pressing R/S after the f'(x) 77. For some reason the code doesn't seem to want to start executing....

- Pauli


Or wrapper the f'(x) call in a program and it runs all the way through.

- Pauli


The manual says lower case x -- so it is wrong :-) Well, it doesn't agree with the code.

It's simply more consistent than the code :-) The command is called f'(x) so the routine for the step size should be called δx (i.e. lower case delta and lower case x) ...


We accept any case now and f' seems to work okay again.

- Pauli


Another question, Pauli:

Is there a special reason that you've chosen 0.1 as default value for this dX (if no user-defined deltaX exists)?

For me this value 0.1 seems really a bit big, I guess I would have used dx=1e-3 if I had written such a f'(x) routine (but of course I don't know the details of your 10-point approximation method).

And if someone arguments that for big x-values adding such a small dx may not change x (or f(x+dx) may not be different to f(x)), well - then it might even be better to make this default dx dependent of the value of x.

Just an idea ...


Edited: 24 Apr 2012, 7:31 a.m.


No real reason to choose 0.1, many similar values will be as good. I needed a default value and that's what I picked, the choice of the delta is really dependent on the problem being solved more than anything else. It is, however, possible to choose too small a value -- I did originally although I don't remember exactly what I picked. I do remember it didn't seem all that small at the time.

Jean-Marc Baillard's numerical derivatives for the 41c chooses similar values for dX and also lists the 10 point formula I used.

BTW: the 34s will fall back to a six point or a four point formula if flag D is set and problems occur -- I don't expect most people to ever discover this but it is there for the more numerically savvy.

- Pauli


I remember that there has been auch a predefined global label 'deltaX' in previous versions, which was even listed in the CATalog. Now I can't find it anymore - has it been removed intentionally?



Yes this label was removed intentionally.

It was primarily there to ensure the CAT browser always found something :-) Marcus's rework of CAT avoided the issue.

- Pauli


We are working on the issue. Calling a user label from XROM needs special precautions which aren't met yet.

Possibly Related Threads...
Thread Author Replies Views Last Post
  [WP-34S] Unfortunate key damage with update to V3 :( svisvanatha 5 963 12-10-2013, 11:37 PM
Last Post: Les Bell
  WP-34S (Emulator Program Load/Save) Barry Mead 1 534 12-09-2013, 05:29 PM
Last Post: Marcus von Cube, Germany
  DIY HP 30b WP 34s serial flash/programming cable Richard Wahl 2 754 12-04-2013, 11:14 AM
Last Post: Barry Mead
  WP 34S/43 ?'s Richard Berler 3 682 11-10-2013, 02:27 AM
Last Post: Walter B
  My FrankenCulator (wp-34s) FORTIN Pascal 4 699 11-09-2013, 06:18 PM
Last Post: FORTIN Pascal
  WP 34S Owner's Handbook Walter B 5 916 11-09-2013, 05:34 PM
Last Post: Harald
  wp 34s overlay and programming. FORTIN Pascal 6 936 11-08-2013, 01:28 PM
Last Post: Nick_S
  m.dy in display of WP-34S Harold A Climer 3 580 11-05-2013, 11:28 AM
Last Post: Andrew Nikitin
  WP 34s : An old problem coming back Miguel Toro 2 537 11-05-2013, 03:00 AM
Last Post: Marcus von Cube, Germany
  [WP 34s] Pressure Conversion Factors Timothy Roche 8 1,034 11-04-2013, 07:17 PM
Last Post: Dave Shaffer (Arizona)

Forum Jump: