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
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.
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 16digit 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 1E14. Rounded in ALL mode, this still remains 1E14 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 16digit 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,51E12 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 wellknown workaround from the olden days may be used: round small function results to zero. In this case, changing x by 1 ULP (1E15) will change f(x) by more than 3E14, so anything below 1E13 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.
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.934654E12 will round to 0 in FIX 11, but not in SCI or ALL display modes.
So, that's the thing. Thank you!
Les
Quote:
... since there is a dedicated CUBE function, as well as CUBERT ...
What, no
Q*bert function?
What about CUTEBERT, the adorable function!
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