HP Forums
solve failure - Printable Version

+- HP Forums (https://www.hpmuseum.org/forum)
+-- Forum: HP Calculators (and very old HP Computers) (/forum-3.html)
+--- Forum: HP Prime (/forum-5.html)
+--- Thread: solve failure (/thread-17749.html)



solve failure - yingwuluo - 11-26-2021 03:45 AM

solve failure


RE: solve failure - rawi - 11-26-2021 07:07 AM

Hi,

I tried with my handheld prime and it worked fine as well in CAS mode as in not-CAS-mode.
But in the PRIME PRO app for Windows I got a syntax error which surprised me (see attached file).[attachment=10064]


RE: solve failure - chromos - 11-26-2021 07:44 AM

(11-26-2021 07:07 AM)rawi Wrote:  ... in the PRIME PRO app for Windows I got a syntax error...

Digit Grouping 123456,789 maybe?


RE: solve failure - rawi - 11-26-2021 08:36 AM

Chronos wrote:
Quote:Digit Grouping 123456,789 maybe?

I do not think so. The input for the handheld Prime was exactly the same as the input for the app. The points after three digits were no input done by me but were added by the calculator. I checked my input with the Help function and could not find any error.


RE: solve failure - yingwuluo - 11-26-2021 10:39 AM

Sometimes right and sometimes wrong, unstable


RE: solve failure - Arno K - 11-26-2021 02:57 PM

Well, on mine it works, you should switch to radians, I think.
Arno


RE: solve failure - yingwuluo - 12-01-2021 06:36 AM

Set to radians, it still fails


RE: solve failure - Nigel (UK) - 12-01-2021 09:44 AM

Is there anything stored in \(x\)? Try purging this variable first. I cannot reproduce your problems on my machine, but storing a function in \(x\) does cause the solve() to fail.

Which firmware version are you using?

Nigel (UK)


RE: solve failure - Albert Chan - 12-01-2021 12:50 PM

(12-01-2021 09:44 AM)Nigel (UK) Wrote:  I cannot reproduce your problems on my machine, but storing a function in \(x\) does cause the solve() to fail.

I tried on HP prime emulator, build 2.1.14181 (2018 10 16)
There is a bug for solve, with pi in it.

Cas> purge(x)
Cas> k := 10^6
Cas> solve(3.0*k = k*10^5*π^2/x^2,x)       → {−573.573720955,573.573720955}
Cas> k *= 10
Cas> solve(3.0*k = k*10^5*π^2/x^2,x)       → {−573.573720955,573.573720955}
Cas> k *= 10
Cas> solve(3.0*k = k*10^5*π^2/x^2,x)       → []

Same behavior if we replace 3.0 with integer 3

BTW, XCas had the same bug.
But, if we use integer 3 instead, the bug show up much later.

XCas> k := 10^93 :;
XCas> solve(3*k = k*10^5*π^2/x^2,x)       → [-100*√(30)*pi/3, 100*√(30)*pi/3]
XCas> k *= 10 :;
XCas> solve(3*k = k*10^5*π^2/x^2,x)       → []

Pulling pi^2 outside solve fixed it.

XCas> solve(3*k = k*10^5*c/x^2,x) (c=pi^2) → [-100*√(30)*pi/3, 100*√(30)*pi/3]

Pi bug should be fixed. For now, use fsolve instead.


RE: solve failure - parisse - 12-01-2021 01:41 PM

If an input has one approx data, like 3.0, then approx will infect all the input (like a virus). pi will be converted to 3.14.. etc.
The first solver step finds the roots, but there is an additional numerical check in the exact solver code to make sure a wrong root is not returned with a tolerance for approx computations errors. Multiplying the equation by a large number will make this test fail and the root is discarded. The rule is it's better to miss some solutions than return too many solutions.


RE: solve failure - Albert Chan - 12-01-2021 02:46 PM

(12-01-2021 01:41 PM)parisse Wrote:  If an input has one approx data, like 3.0, then approx will infect all the input (like a virus). pi will be converted to 3.14.. etc.

Even if input has no approx data, it sometimes "infected" to approximate value.

Cas> solve(3*10^10 = 10^15*c/x^2, x) (c = π^2)

Above sometimes gives exact solution, sometimes approximate.


RE: solve failure - parisse - 12-01-2021 07:00 PM

Numerical check happens if the equation does not depend on parameters.


RE: solve failure - yingwuluo - 12-07-2021 03:05 AM

[attachment=10160]