WP 34S

[Richard Berler]

Concerning the use of f '(x), I discovered that as is the case with the HP 15C LE, the SCI mode is sometimes the way to go. When solving for f '(x) =0 for x^2 * e^-x over the interval 1-3, fix 4 came up 2.0001. That didn't seem right. In SCI 4 mode, it comes up as 2.0000. Upon checking, it did not vary from 2 until the 12th. digit!

[Paul Dale]

This is both rather surprising & concerning because neither f' nor solve depend on the display mode. It also isn't reproduced with version 3344 firmware or with the version 3366 console emulator.

The following program returns 1.999999999998732 when run in FIX 04 mode. This displays as 2.0000.

    001:  LBL A

    002:  1

    003:  ENTER[^]

    004:  3

    005:  SLV 01

    006:  RTN

    007:  RTN

    008:  LBL 01

    009:  f'(x) 00

    010:  RTN

    011:  LBL 00

    012:  x[^2]

    013:  x[<->] Y

    014:  +/-

    015:  e[^x]

    016:  [times]

    017:  RTN

    018:  END

- Pauli

[Robert Prosperi]

To learn a bit more about the 34S (never used the f'(x) Fn) I keyed this in, just to follow along. Interestingly, I get 0.0035, so I must be doing something wrong. Are there other (not stated) settings or assumptions required?

I have verified the program steps several times, I believe I have recreated the same program.

I just reflashed last week to 3.2T 3371.

--bob

[Dieter]

If you are using Pauli's code try replacing line 013 with a RCL L. Or add a FILL after LBL 00, or simply use my version below. Does this solve the problem?

Dieter

[Robert Prosperi]

Thanks Dieter, for quick reply.

Yes, both suggestions produce the expected result. I also can reproduce your results with your code.

Is this the same bug discussed earlier this week relating to FILL? If so, I believe it has already been corrected and I only need to reflash.

Can someone provide a short explanation, if it matters, or is this simply a small bug?

Thanks!

--bob

[Walter B]

The "missing FILL" bug was repaired with build 3376. When you've updated your WP 34S to said build everything should be ok AFAIK.

d:-)

[Robert Prosperi]

Just checked at SF.net and the latest build posted is 3375 (according to the revision.txt file.

I'm not rushing things, I just note the status as I initially interpreted Walter's comment to mean that it was available.

No rush, I'll check back in a day or so.

Thanks.

--bob

[Robert Prosperi]

It just occurred to me to check the individual .../tree/trunk... builds, and 3376 is indeed there, and after reflashing, the program works as expected.

Thanks to all for your quick replies and patience.

--bob

[Gerson W. Barbosa]

Is http://svn.code.sf.net/p/wp34s/code/trunk/realbuild/ (p/wp34s/code - Revision 3376: /trunk/realbuild) the correct link? I've download calc_ir_full.bin and reflashed, but VERS still returns 3371 here. Thanks!

[Robert Prosperi]

I found the 3375 files here:
http://sourceforge.net/p/wp34s/code/3376/tree/trunk/realbuild/

--bob

[Robert Prosperi]

Darn! 3375 s/b 3376. Typed too fast

[Gerson W. Barbosa]

I've downloaded http://sourceforge.net/p/wp34s/code/3376/tree/trunk/realbuild/calc_ir_full.bin, but still no joy. This time I erased the memory before flashing. I will try other images.

[Robert Prosperi]

Should not make a difference, but I used the file calc_xtal_full.bin as I don't have IR in mine (but do have the clock).

--bob

[Gerson W. Barbosa]

Thanks, calc_xtal_full.bin worked! Now I have 3.2T 3376. It seems calc_ir_full.bin is still 3371.

[Marcus von Cube, Germany]

Quote:

---

It seems calc_ir_full.bin is still 3371

---

I cannot confirm your findings. BTW 3375 and 3376 are identical, It was just an (unnecessary) rebuild. Do you use an SVN client to check out the repository or do you navigate with a browser? The Revision number can be seen in the binary file at its very end (but before the library code) in plain ASCII. It's easiest to check with the calc_xyz.bin file.

[Gerson W. Barbosa]

Quote:

---

Do you use an SVN client to check out the repository or do you navigate with a browser?

---

The latter (I assume the former is the right way, but I don't know how to do it). This is the link:

http://sourceforge.net/p/wp34s/code/3376/tree/trunk/realbuild/calc_ir_full.bin?format=raw

The file I get this way doesn't solve the automatic FILL problem and upon reflashing VERS returns 3375. I can live with that until the next distribution is available. Solve & Integrate are more important than printing :-)

[Marcus von Cube, Germany]

The file is definitely a version 3376. It's emulator sibling is filling the stack correctly during a SLV. I simply do not understand how you get to a 3375 VERS display at all. I'll reflash my dev unit and check again.

[Gerson W. Barbosa]

I've found this tip from Franz in the WP 34s emulator thread above:

"If you get an older one then it doesn't come from Sourceforge but from your browser cache (or from the cache of your internet provider)."

I download the file using the IE browser instead of Chrome and it's indeed 3376. Sorry for the confusion.

[Richard Berler]

Hi Pauli,

I have version 3.1.3278

I'm 58 nearing 59, and know enough to be dangerous and inefficient in my programming efforts.

I wrote:

LBL F0
X^2
X<>y
+/-
e^x
*
RTN
LBL F1
FILL (didn't matter if I included this step in the behavior of the routine)
f '(x) F0
RTN
END

I use solve from the keyboard so that I can input the interval without entering the program (in this example, I input 1 enter 3 SLV F1 enter).

In fix 4, I get 2.0001. Interestingly, SCI 4 yields your result! Perhaps even odder is that fix 8 comes close to your result and fix 12 is a tiny hair better than your result from your run on fix 4.

Any ideas?

P.S. I am in SSIZE 8. Behaved the same in size 4 regardless if I included the fill command.

Richard

[Richard Berler]

Just to be clear, I'm in regular precision (although that did not improve my results).
On fix 8, I get 2.00000000004169
On fix 11 (no fix 12), I get 1.999999999998734

On fix 4, I get 2.000128719623704

On SCI 4, I get 1.999999999998732

Richard

[Paul Dale]

I'd suggest upgrading to the latest firmware. Solve was dependent on the display mode setting for a long time and I changed this a while back. I'm guessing here but I think you've got the old code.

Current firmware doesn't care about the display mode setting.

- Pauli

[Marcus von Cube, Germany]

Do you have [delta]X defined?

[Dieter]

Richard, it would be nice if you would choose a more meaningful subject. Else we will end up with a dozen different threads all titled "WP 34S". ;-)

I tried your example on a (hardware) 34s running version 3.2 3360, without a custom defined delta-x, and the result was always the same:

  LBL 01

  f'(x) 00

  RTN

  LBL 00

  x^2

  RCL L

  e^x

  /

  RTN

 

  1 [ENTER] 3

  SLV 01  =>  1,999 9999 9999 8726

Which is displayed as

  2,0000   in FIX 04

  2,0000 0 in SCI 04

  2        in ALL 03

Defining delta-X = 0,0001 yields one more valid digit:

  1,999 9999 9999 9809

Again, independent from the display setting.

Dieter