[WP 34S] Expanded and rearranged manual available

[Walter B]

I'm at 190 pages now. I made the first steps a bit easier (IMO), put the harder stuff towards the center, and moved the major part of equations into an appendix. Added quite some pictures, plots, and links. Learned not everybody using scientific calcs loves math equations ;-) Still found and removed some errors.

Look here for build 3231 and enjoy d:-)

Questions and error reports continue being appreciated.

[Reth]

Beautiful! And thanks for MOD being presented in the latest release!

[Paul Dale]

MOD has been there for a few weeks now. Both integer and real of course.

- Pauli

[Reth]

Thanks a lot for that, I missed it somehow. Cheers

Edited: 18 Aug 2012, 4:51 a.m.

[Dieter]

I don't know whether this is a problem of the manual or the current implementation, and the way SLV works has been discussed recently, but anyway:

SLV seems to work better than in previous versions. For instance it no longer throws an error if the best possible function result exceeds 1E-16. However, either the implementation or the manual is wrong: the latter states that the user provides two guesses and "for the rest, the user interface is as in the HP-15C". It's not. And since the algorithms in the 15C and 34s are completely different, also the results differ. So this reference is misleading.

Example (tested on 3.1 3225):

LBL 99

X^2

 2

 -

RTN

 

FIX 4

1 [ENTER] 2 [SLV] 99  => X=1,4142  Y = 1,4166  Z = 1,4142 (= X)

Do the same on a 15C (or 34C) and X and Y will contain the two best possible solutions 1,414213562 resp. ...63 while Z holds f(X) = -1E-9.

Or try the previous example with initial guesses 2 and 3. This will throw a +infinity error on the 34s, while the classis HPs return the correct result.

So the 34s obviously does not return the same results, and unlike the 15C/34C it also does not return f(X) in Z (which in this case would be approx. -9E-11). The accuracy of the result depends from the display setting, i.e. FIX 4 and ALL will return different results. These are only as exact as the display setting, while the 34C/15C always return the best possible root(s). This behaviour should get documented and the 15C reference should be omitted.

Please don't get me wrong: SLV works well, but it is completely different from the 15C/34C. And yes, I would like to get results that are independent from the display setting. But the essential point is that the manual and the way the 34s works simply do not agree.

Dieter

[fhub]

Yes you're right, it's indeed a bug in the SLV command.

I've just looked at the xrom file solve.wp34s and the description says that Z should hold f(x) - but it doesn't.

BTW, I would even prefer that f(x) should better be in Y instead of Z.

Reasons:

1) it's much more important to look if f(x) is near 0 than seeing the previous root iteration, and x<>y is faster than twice RDN

2) and calling the function value y (=f(x)) is quite usual, so it would indeed better fit into the Y register.

Franz

[Dieter]

Quote:

---

BTW, I would even prefer that f(x) should better be in Y instead of Z.

---

If you look at the way Solve works on the 34C/15C, returning two approximations in X and Y makes perfect sense. Here they define an interval that contains the exact root for which the function result becomes exactly zero. With limited precision arithmethics there often is no n-digit value that satisfies this condition.

Take the example I posted before: f(1,414213562) returns -1E-9, and f(1,414213563) is +2E-9, Assuming a continuous function, the true value must be somewhere between these two. So Solve here actually gives some additional information: Neither X nor Y will satisfy f(x)=0 exactly (examine Z to see how close f(X) gets), but these two are the closest possible solutions.

I am not sure whether the 34s SLV implementation also claims the true solution is somewhere in [X, Y]. If it doesn't, this is another point where the user interfaces of the 34C/15C and 34s Solve differ. You may try the previous example (in single precision) with a 7 instead of 2. Since there is no 16-digit value whose square is exactly 7 (to 16 digits), this should return 2,645751311064590 and 2,645751311064591 in X resp. Y. In ALL mode this actually is what the 34s (3.1 3225) returns. However, it should do so in any display mode.

So, yes, I think if the 34s in this way behaves like the 34C/15C, it should return the two closest solutions in X and Y.

Dieter

[Paul Dale]

Definitely a bug, the solver was intended to produce the same stack results as the 34C/15C.

Hopefully fixed now. Well, the correct value is going into Z on success.

The value in Y might not be all that close to the equivalent value from the 34C/15C for a number of reasons.

- Pauli

[Reth]

Quote:

---

Hopefully fixed now.

---

Where? New built?

[Paul Dale]

The new build is in subversion. It isn't in the releases archive yet.

- Pauli

[Reth]

I tried your firstfirst example on my just reflashed wp34s and found another strange thing. To check if Z contained X exactly I did RCL- Z and it gave me out of range error.