CODEWITHSUNDEEP
matlabsymbolic-mathmapleinequality
Bruno
Bruno

Reputation: 1471

MATLAB's Symbolic Math Fails to Solve a Simple Inequality

I have a simple inequality and MATLAB's Symbolic Math toolbox is doing something very strange. Here are the variables:

>> syms X ndot4B xiA ndot4A xiB

I'm trying to solve the following inequality (please do it yourself "on paper"):

>> solve(X*ndot4B*xiA - ndot4B*xiA + X*ndot4A*xiB > 0, xiA)

The answer is:

ans =

(X*ndot4A*xiB - 1)/(ndot4B - X*ndot4B)

But this is not correct. If instead I solve it as an equality:

>> solve(X*ndot4B*xiA - ndot4B*xiA + X*ndot4A*xiB, xiA)

The result is:

ans =

(X*ndot4A*xiB)/(ndot4B - X*ndot4B)

The above is correct (i.e., xiA has to be greater than the solution above). The difference is in the numerator. Maple gets it right (as it should). Any ideas on what may be going on? It's hard to believe that MATLAB would screw up on such simple calculation.

EDIT:

Based on horchler's answer, I tried solving the same inequality using assumptions on both MATLAB and Maple.

MATLAB:

Maple:

I still find MATLAB's answer very strange...

Upvotes: 2

Views: 894

Answers (2)

Karan Gill
Karan Gill

Reputation: 158

solve's answer is correct. You simply need some positive value in the numerator to satisfy the inequality. It can be any value, hence solve introduces a parameter.

You can verify your proposed answer and solve's answer as:

syms X ndot4B xiA ndot4A xiB
eqn = X*ndot4B*xiA - ndot4B*xiA + X*ndot4A*xiB > 0;
trySol = (X*ndot4A*xiB)/(ndot4B - X*ndot4B); % let's try the proposed answer
tryCondition = subs(eqn,xiA,trySol); % substitute the answer to get the condition
isAlways(tryCondition) % check if the condition holds?
ans =
  logical
   0

The condition doesn't hold. Now try solve's answer with the same steps:

trySol = (X*ndot4A*xiB - 1)/(ndot4B - X*ndot4B);
tryCondition = subs(eqn,xiA,trySol);
isAlways(tryCondition)
ans =
  logical
   1

This answer is correct. You can check on paper yourself by substituting these two values for xiA. You just need some positive value in the numerator to satisfy the > inequality. For example, even using eps instead of 1 will work:

trySol = (X*ndot4A*xiB - eps)/(ndot4B - X*ndot4B);
isAlways(subs(eqn,xiA,trySol))
ans =
  logical
   1

As horchler pointed out, if you change the > to ==, then you don't need the positive value.

solve introduces assumptions, X~=1 and ndot4B~=0, because when you divide both sides of an inequality by a constant, then that constant cannot be 0.

Hope this helps.

Upvotes: 0

horchler
horchler

Reputation: 18484

Your system is ill-defined. You (and perhaps Maple) are making some assumptions that aren't necessarily true or that are at least different from each other. When solving inequalities, it's best to use the 'ReturnConditions' option to see the full details of the solution. In your case:

syms X xiA ndot4B ndot4A xiB
s = solve(X*ndot4B*xiA - ndot4B*xiA + X*ndot4A*xiB > 0, xiA, 'ReturnConditions', true)

This returns a data structure:

       xiA: [1x1 sym]
parameters: [1x1 sym]
conditions: [1x1 sym]

Now you'll see that there is an additional parameter (s.parameters is x) and set of conditions (s.conditions is X ~= 1 & ndot4B ~= 0 & 0 < x). The solution, s.xiA, is a function of the parameter:

-(x - X*ndot4A*xiB)/(ndot4B - X*ndot4B)

Because you are solving this with the strict inequality (> rather than >=), the parameter x can't actually be equal to zero to guarantee satisfying the inequality (Maple may treat the two cases the same, I'm not sure).

So why does Matlab's symbolic engine (not quite the same as the MuPAD environment) return (X*ndot4A*xiB - 1)/(ndot4B - X*ndot4B) when you don't ask for the return conditions? Firstly, this answer satisfies the inequality and is perfectly valid given that there is no information (assumptions) about the ranges of each variable. Rather than return an error or warning, it looks like Matlab just chose the first integer value of the parameter x that would satisfy the conditions, i.e., 1. It appears to treat the <= case similarly, but for some reason does not choose 0 for x (which would match the ==). I suggest filing a service request if you want to try to ask The MathWorks why this is and if it might be a bug of some sort.

I also recommend learning about and using assumptions when working with solve.

Upvotes: 2

Related Questions