Post Reply 
Result from solve() command shows c_0
03-19-2020, 06:53 AM
Post: #1
Result from solve() command shows c_0
When solving the equation as in the picture, the calculator return c_0^2 +1

What does the c_0 mean?

[Image: pic2.png]
Find all posts by this user
Quote this message in a reply
03-19-2020, 07:05 AM (This post was last modified: 03-19-2020 07:21 AM by parisse.)
Post: #2
RE: Result from solve() command shows c_0
c_0 is any real (solve algorithm introduces auxiliary unknowns to solve equations with sqrt, c_0 is one of them)
Here it would means that any real x that can be written as c_0^2+1 is solution, i.e. x>=1 is solution since c_0^2+1>=1 if c_0 is real.
This is incorrect for all c, but valid for c in [2,3], i.e. x in [5,10]
Try this
Code:
f:=sqrt(x+3-4*sqrt(x-1))+sqrt(x+8-6*sqrt(x-1))
then
Code:

assume(c>0)
simplify(f(x=c^2+1))
You can confirm this with plot(f,x=4..11)
Find all posts by this user
Quote this message in a reply
03-20-2020, 09:51 AM
Post: #3
RE: Result from solve() command shows c_0
The calculator for this equation gives a difficult record of the solution for CAS Settings-Exact. When we leave this setting, we get a numerical sequence of solutions in the range (5, 10). The correct solution for this equation should be x≥5 AND x≤10. I checked how inequalities are made. Unfortunately, the calculator for this example gives the wrong solution. (See the attached screenshot) Then I changed the equation: √ (x + 3-4 * √ (x-1)) + √ (x + 8-6 * √ (x-1)) = 2.
The solutions to this equation and inequalities are correct. For all other numbers> 1, solutions of equations and inequalities are correct. Then I checked how HP PRIME virtual performs these equations and inequalities (for different CAS settings) Here is the tragedy. This calculator gives no solutions or gives them incorrectly.


               
Find all posts by this user
Quote this message in a reply
03-21-2020, 06:26 AM
Post: #4
RE: Result from solve() command shows c_0
This is an endless debate. A CAS can not think for you, it will make computations for you. If you see an unusual answer for a tricky input, you have to connect your brain and interpret the answer, with the help of additional commands (like plot for example).
Find all posts by this user
Quote this message in a reply
03-21-2020, 10:19 AM
Post: #5
RE: Result from solve() command shows c_0
My opinion on this topic is clear. When I solve an equation or inequality on paper, I can make a mistake. But then I check them on the calculator. But when the calculator makes mistakes, that's not good. The calculator should do mathematical operations perfectly and error-free. People want to have confidence in the calculator (this is to be a reliable teacher). That's why I have a request to Parisse.
Please correct the solution to this unique equation and inequality. Not all are geniuses like you.
Find all posts by this user
Quote this message in a reply
03-21-2020, 10:40 AM
Post: #6
RE: Result from solve() command shows c_0
(03-21-2020 10:19 AM)Jan 11 Wrote:  My opinion on this topic is clear. When I solve an equation or inequality on paper, I can make a mistake. But then I check them on the calculator. But when the calculator makes mistakes, that's not good. The calculator should do mathematical operations perfectly and error-free. People want to have confidence in the calculator (this is to be a reliable teacher). That's why I have a request to Parisse.
Please correct the solution to this unique equation and inequality. Not all are geniuses like you.

+1

Tom L
Cui bono?
Find all posts by this user
Quote this message in a reply
03-21-2020, 10:42 AM
Post: #7
RE: Result from solve() command shows c_0
(03-19-2020 06:53 AM)teerasak Wrote:  When solving the equation as in the picture, the calculator return c_0^2 +1

What does the c_0 mean?

[Image: pic2.png]

There seem to be a whole range of solutions. What would you expect to see?

Tom L
Cui bono?
Find all posts by this user
Quote this message in a reply
03-22-2020, 02:10 AM
Post: #8
RE: Result from solve() command shows c_0
@toml_12953, I need to understand what is c_0? And expect calculator return a correct result which is [5,10].
Find all posts by this user
Quote this message in a reply
03-22-2020, 08:36 AM
Post: #9
RE: Result from solve() command shows c_0
Sorry if I didn’t make the point clear.

I got the point about C_0 now which is another dummy variable to solve equation.

However, with this result, it doesn’t tell me the final answer. And to find out the answer, I need to figure out in other way e.g plotting the graph. I know we can use that way.

It will be good if we can improve this so that we can batter utilize our calculator.
Find all posts by this user
Quote this message in a reply
03-22-2020, 09:20 AM
Post: #10
RE: Result from solve() command shows c_0
I did that with the Nspire:

[Image: irrequ.jpg]

[Image: graphirr.jpg]

Best,
Aries Wink
Find all posts by this user
Quote this message in a reply
03-22-2020, 01:39 PM
Post: #11
RE: Result from solve() command shows c_0
I also tried with the nspire (without absolute value like in Aries screenshot, with version 4.0.3.29 of the nspire os), and I got a strange "true" answer.
[Image: solve_nspire.png]

Just to show that, well, it's not something easy to implement. The Prime returns too many solutions. One could argue that it suffices to verify which part of the returned set is solution. But even if I had an idea how to implement that, adding checks would certainly have bad side-effects, it would probably slow down some other solve commands, perhaps block some commands. It's very hard to find a good compromise, especially on a calculator where interruption is hard to implement. And someone would certainly find another input that the calc would not solve automatically.

Therefore, I'm sorry, but I won't change that code, it's far too risky. As I said, at some point, you must connect your brain. The calculator is a tool, it *computes* much better than humans, it will help you a lot once you know how to use it, but it will not think for you.
Find all posts by this user
Quote this message in a reply
03-22-2020, 02:44 PM (This post was last modified: 03-22-2020 02:45 PM by DrD.)
Post: #12
RE: Result from solve() command shows c_0
Quote: ... But even if I had an idea how to implement that, adding checks would certainly have bad side-effects, it would probably slow down some other solve commands, perhaps block some commands. It's very hard to find a good compromise, especially on a calculator where interruption is hard to implement. And someone would certainly find another input that the calc would not solve automatically.

Parisse,

Somewhat related (Example): taking the limit of LN(x) as x->0, or as x->0^-, doesn't make a lot of sense for x negative reals. Rather than risk breaking complex code, would adding a warning message be appropriate here?

Thank you for your very valuable insight, and I hope that you can remain safe and healthy, in our complicated world these days!

   

-Dale-
Find all posts by this user
Quote this message in a reply
03-22-2020, 04:40 PM
Post: #13
RE: Result from solve() command shows c_0
I am sorry but neither Nspire nor HP Prime are right. The solution is x in [5,10]

HP prime solution is [1, +infinity]
Nspire solution is x = any real number ("true" means that the two expressions are algebraically equivalent for all x.)

Both calculators provide too many solutions. In fact, the solutions are not that bad because both calculators understand that there is a continuous set of solutions.

For comparison, Wolfram alpha solution is correct https://www.wolframalpha.com/input/?i=so...%29%29%3D1 but for exemple my old version Maple (Maple 14 - 2010) gives any real number.
Find all posts by this user
Quote this message in a reply
03-22-2020, 05:48 PM
Post: #14
RE: Result from solve() command shows c_0
Graphing certainly sheds light on this, and is welcome in light of difficulty of solve with solutions on a continuous interval. The CASIO fx-CG50 makes for a nicely labeled graph if an appropriate window view is chosen. Trace capability confirms the solution over the 5 to 10 domain nicely.
Find all posts by this user
Quote this message in a reply
03-23-2020, 03:41 PM (This post was last modified: 03-23-2020 03:42 PM by parisse.)
Post: #15
RE: Result from solve() command shows c_0
@jfdHP: Indeed! On a computer (or a server), you can add more checks without fearing bad side-effects like on a calculator. And Wolfram has much more programmers to implement special code for specific inputs like that...

@lrdheat: for efficiency reasons, the first step in a limit computation (without discontinuous fonctions like floor) is substitution, if the answer is not undef or unsigned inf, then it is considered to be correct. ln(0) is -infinity, therefore it is returned without further computation, and one could argue that, since ln(x) for x negative is ln(-x)+i*pi, the limit *is* correct.
Find all posts by this user
Quote this message in a reply
03-23-2020, 11:26 PM
Post: #16
RE: Result from solve() command shows c_0
@parisse Thaks for the response. I do agree.

Thinking about this issue, I found another (simple) example about the problem of simplifying square roots.
Try
simplify(sqrt(x^2-6*x*sqrt(x-2)+9*x-18)
We obtain (with HP prime - I checked that XCas provides the same answer) :
3*|sqrt(x-2)| - |x|*sign(x)
A priori this is a very nice result, because the CAS understood that there was a not obvious simplification. For comparison, in that example Wolfram alpha or Maple 14 are not able to simplify anything. Considering the fact that a square root is always positive, the CAS could have given the simpler equivalent result 3*sqrt(x-2) - x but this is not a big problem.

The problem is that the answer is not correct for any value of x. In fact we have x^2-6*x*sqrt(x-2)+9*x-18 = (x-3*sqrt(x-2))^2 so that the general solution is in fact
|x-3*sqrt(x-2)|
Thus the result given by the CAS is valid only when 3*sqrt(x-2) - x > 0 , i.e. for 3 < x < 6. Elsewhere, there is a sign problem.

Thus it is surprising to see that the CAS finds the simplification trick, which is not obvious at all, but it did not succeed in managing the sign issue whereas a priori (for a human being), it is much simpler in this example. For practical use, I would say that this sign issue is a little bit more serious than the solve question because we know for solve that a universal solver does not exist so that we have to be cautious with the given solutions, but for a relatively simpler simplification it is a little bit more surprising.
Find all posts by this user
Quote this message in a reply
03-24-2020, 06:53 AM (This post was last modified: 03-24-2020 06:57 AM by parisse.)
Post: #17
RE: Result from solve() command shows c_0
This is not a simple expression for a CAS (and that's why some other CAS will not simplify it).
The partially incorrect answer is a consequence of the algorithm used by simplify to handle sqrt and fractional powers. It will construct a unique algebraic extension of Q or Q[parameters] and write the expression as an irreducible fraction. But at some points, we must choose between different branchs (that is different solutions of a polynomial equation). When no parameters are involved, the choice of branch is done using numeric evaluation. If there are parameters, the choice is done by giving values to the parameters. The values of the parameters will take care of assumptions.
For example here, if you run
assume(2<x<3)
before simplify, you will get the right answer in this interval.

As a consequence, if you simplify expressions with sqrt (or fractional powers) with parameters, you should check the answer and add assumptions. For example here,
f:=sqrt(x^2-6*x*sqrt(x-2)+9*x-18;
g:=simplify(f);
plot(g-f,x,2,10)
will help you make the right assumption.

If you want to make sure that nothing like that happens, you can run ratnormal. ratnormal will handle sqrt and fractional powers like an independant algebraic variable. But it will of course not simplify this expression.
Find all posts by this user
Quote this message in a reply
03-24-2020, 12:04 PM
Post: #18
RE: Result from solve() command shows c_0
Thank you very much for the response. Yes I do agree that it is not a simple simplification. In fact, my concern was just the fact that the CAS did the complicated part of the job, but not the sign part that was a priori, for a human being, much simpler!

Now I understand that the algorithm is more complex than the "human" one. In fact the CAS does not realize directly that
x^2-6*x*sqrt(x-2)+9*x-18 = (x-3*sqrt(x-2))^2
so that the calculation of the square root is not so easy. It uses what it knows better: polynomial and rational functions. If it uses a polynomial representation, I can imagine that it defines a=sqrt(x-2) in order to get a simple polynomial:
x^2-6*x*sqrt(x-2)+9*x-18 = a^4-6*a^3+13*a^2-12*a+4
Then it uses its (powerful) root finder of polynomial functions to get
a^4-6*a^3+13*a^2-12*a+4 = (a-2)^2*(a-1)^2
Then it can take the square root to obtain
|(a-2)*(a-1)|
Then it can go back to x with a=sqrt(x-2)
|(sqrt(x-2)-2)*(sqrt(x-2)-1)|
Finally it can expand the product to obtain:
||x-2|-3*sqrt(x-2) +2|
Normally there is no sign problem in this path. I presume that the CAS does it in a similar way but the substitution is more complicated than a=sqrt(x-2) so that there is a choice of branch which can lead to a sign problem for some values of x.

I can imagine that the problem is the same for the solve command for these algebraic expressions. As long as the CAS chooses a branch, there is a loss of generality and potentially sign errors.

Maybe a warning message during the CAS calculation could be welcome. The trick of using "assume" to force the CAS to go to the relevant part in the x domain is very nice; it could also be a good idea to say something about it in the warning message.
Find all posts by this user
Quote this message in a reply
03-24-2020, 07:57 PM
Post: #19
RE: Result from solve() command shows c_0
Indeed, I just made a commit for that.
Find all posts by this user
Quote this message in a reply
04-14-2020, 02:46 PM
Post: #20
RE: Result from solve() command shows c_0
(03-22-2020 01:39 PM)parisse Wrote:  I also tried with the nspire (without absolute value like in Aries screenshot, with version 4.0.3.29 of the nspire os), and I got a strange "true" answer.
[Image: solve_nspire.png]

Just to show that, well, it's not something easy to implement. The Prime returns too many solutions. One could argue that it suffices to verify which part of the returned set is solution. But even if I had an idea how to implement that, adding checks would certainly have bad side-effects, it would probably slow down some other solve commands, perhaps block some commands. It's very hard to find a good compromise, especially on a calculator where interruption is hard to implement. And someone would certainly find another input that the calc would not solve automatically.

Therefore, I'm sorry, but I won't change that code, it's far too risky. As I said, at some point, you must connect your brain. The calculator is a tool, it *computes* much better than humans, it will help you a lot once you know how to use it, but it will not think for you.

Hey parisse,
solving irrational equations can be extremely complicated for the CAS, especially when a solution results in an interval, this is a limitation of the CAS.
I'll be looking into this and ... in the meantime, I recommend using the modulus as pointed out above.
Best,

Aries Wink
Find all posts by this user
Quote this message in a reply
Post Reply 




User(s) browsing this thread: 2 Guest(s)