I've tested now the new error message "Solve failed" for the SLV command and in principle it is working. But in my tests I saw that SLV is still working unreliable.

I've used the simple function x^2-3 and found that the solver has big problems when the 2 initial guesses are equal - and this may happen quite quickly when the user presses the ENTER key after his 2nd guess and before calling SLV.

Ok, I know that this is in fact an user error, but who has really never done this before: entering 2 start values? - well, 0 ENTER 1 ENTER - and now call the solver? - ok, [f]SLV.

But now of course X=1 and Y=1 and SLV is called with 2 equal guesses - and it fails! Unfortunately not with the new error message "Solve failed" but with completely wrong 'results' in X and Y, and a function value in Z which is far away from 0 (what it should be) - but for THIS problem a bit later.

For the above mentioned function x^2-3 this happens for all initial guesses from -1.7 to +1.7 whenever both guesses are the same.

So I would say that the SLV routine should definitely make sure that it is NOT called with 2 equal inital guesses - either it should give any error message in this case, or the 2nd guess should automatically be changed a bit. One possible solution might be the following short code at the begin of the SLV routine:

x=y?

INC X (or any other change of X)

This might of course lead to another problem when the changed X-value is not within the definition interval of the function, but this would certainly happen not very often and would definitely be better than a wrong result.

And now to the other problem mentioned before: also if (because of such 2 equal start values) the solver fails, it should of course not give wrong results but display the new implemented error message - but it doesn't do it (at least not for the above function and all values -1.7...+1.7.

So there must still be something not ok in the SLV routine; it should in fact NEVER provide a 'solution' (which is none) whenever the function value in Z is not (at least nearly) zero - not even if the last 2 calculated argument values (which are in X and Y) are very close to each other.

You see, this SLV routine needs indeed some further improvements ...

Franz

Should be fixed now.

- Pauli