[WP34S] SLV returns "Failed" when it finds a root just fine.

[Les Wright]

The subject line says it all.

I have encountered a weird situation where the Solver tells me it has failed, but the root returned (once I clear the error message) is more than accurate for the precision specified via, ALL, SCI, or FIX.

I am using 2.2 and this reproducible on the emulator and on the calc.

The very simple equation I am dealing with is x^3 -36 = 0, and the routine solved is

LBL 55

3

y^x

3

6

-

RTN

The real root of this equation is about 3.3. I enter 3 ENTER 3.5 f SLV 55 and I get "Solve Failed", but underneath is a root that is more than acceptable for the precision desired.

Is this a bug? Is the underlying code much more sensitive around the desired error issue than it has to be?

If this issue has already been reported, please forgive my repetition. It is just odd to get a failure message when there has been no failure at all.

Les

[Marcus von Cube, Germany]

This is Pauli's territory, I'm afraid. There are some issues with the solver pretending not to find a root while the results are perfectly fine.

[Dieter]

There is or was a problem with the solver in that it checks whether the function result of the final approximation is close to zero, as far as I know using the x~~0 test. In SCI, ENG or ALL mode this is equivalent to a test whether x is exactly zero. However, in many cases even the best possible 16-digit result does not return a plain zero. And the solver will throw an error.

This is also true in this case. The correct solution is the cuberoot of 36, i.e. 3,301 9272 4889 4627 for which the function result is 1E-14. Rounded in ALL mode, this still remains 1E-14 and not zero, making the solver think it has failed. However, the root SLV has found so far is 3,301 9272 4889 4673 in X and Y, which is not the exact 16-digit value.

Now try the same in FIX 11 mode and the solver returns a result that is correct in all 11 displayed decimals: 3,301 9272 4889. The final function result in Z is 1,51E-12 which in FIX 11 nicely rounds to zero, thus confiming that the solver has found a valid result.

As long as this has not been corrected, the well-known workaround from the olden days may be used: round small function results to zero. In this case, changing x by 1 ULP (1E-15) will change f(x) by more than 3E-14, so anything below 1E-13 may be considered zero. So simply add "EEX 4 + RCL—L" to the function routine and the solver will find a result even in ALL mode.

By the way, there is no need for "3 y^x" since there is a dedicated CUBE function, as well as CUBERT and another one for the xth root of y. These functions also provide better precision.

Dieter

Edited: 27 Nov 2011, 9:51 a.m.

[Les Wright]

Yep, Dieter, that is the thing.

One needs to use FIX n so that the function result in register z rounds to zero for the purposes of the x~~0 test. This won't happen with SCI n or ALL n. For example 2.934654E-12 will round to 0 in FIX 11, but not in SCI or ALL display modes.

So, that's the thing. Thank you!

Les

[Howard Owen]

Quote:

---

... since there is a dedicated CUBE function, as well as CUBERT ...

---

What, no
Q*bert function?

[Les Wright]

What about CUTEBERT, the adorable function!

[Paul Dale]

Dieter hit the nail on the head. The approximately zero test is failing and the solver thinks it hasn't solved successfully.

This errant check has been removed in the latest firmware and it is up to the user to determine if a zero or a discontinuity was found.

- Pauli