Thread Subject: solve in R2008b; absolutely no solution?

In R2008b

>> solve ('abs(x) = x^2')

does not come to a solution at all. Matlab is busy, busy, busy, and busy ...

In R2007b:

>> solve ('abs(x) = x^2')
 
ans =
 
  0
  1
 -1

Obviously, R2008b's MuPAD-Matlab-Interface has quite a hard time trying to interpret the "complex" result MuPAD is trying to communicate to Matlab:

matrix([[x]]) in {matrix([[0]])} union solvelib::Union(Dom::ImageSet(x + y*I, x, R_ intersect RootOf(X82^3 + y*X82^2*3*I - X82*(3*y^2 + 1) + y*I - y^3*I, X82)), y, R_) intersect ({matrix([[0]])} union solvelib::VectorImageSet(matrix([[(-1)^(1/4)*(x + y*I)^(1/2)]]), [x, y], [R_, Dom::Interval(-infinity, 0)]) union solvelib::VectorImageSet(matrix([[-(-1)^(1/4)*(x + y*I)^(1/2)]]), [x, y], [R_, Dom::Interval(-infinity, 0)]))

I feel like the poor MuPAD-Matlab-Interface developers still have a long, long road to go ... ;-)

Put MATLAB 2007b in a .dll and call it in MATLAB 2008b to solve said problem.

Seriously though, calling out MuPad shortcomings is old news now.

"Husam Aldahiyat" <numandina@gmail.com> wrote in message <ggojpq$72l$1@fred.mathworks.com>...
> Put MATLAB 2007b in a .dll and call it in MATLAB 2008b to solve said problem.
>
> Seriously though, calling out MuPad shortcomings is old news now.

You do not have to read my messages.

Joerg Buchholz wrote:
> In R2008b
>
>>> solve ('abs(x) = x^2')
>
> does not come to a solution at all. Matlab is busy, busy, busy, and busy ...
>
> In R2007b:
>
>>> solve ('abs(x) = x^2')
>
> ans =
>
> 0
> 1
> -1
>
> Obviously, R2008b's MuPAD-Matlab-Interface has quite a hard time trying to interpret the "complex" result MuPAD is trying to communicate to Matlab:
>
> matrix([[x]]) in {matrix([[0]])} union solvelib::Union(Dom::ImageSet(x + y*I, x, R_ intersect RootOf(X82^3 + y*X82^2*3*I - X82*(3*y^2 + 1) + y*I - y^3*I, X82)), y, R_) intersect ({matrix([[0]])} union solvelib::VectorImageSet(matrix([[(-1)^(1/4)*(x + y*I)^(1/2)]]), [x, y], [R_, Dom::Interval(-infinity, 0)]) union solvelib::VectorImageSet(matrix([[-(-1)^(1/4)*(x + y*I)^(1/2)]]), [x, y], [R_, Dom::Interval(-infinity, 0)]))
>
> I feel like the poor MuPAD-Matlab-Interface developers still have a long, long road to go ... ;-)

Hi, I believe the reason MATLAB is having a hard time is that the MuPAD
engine assumes by default that symbolic variables are complex. If you
want to look for real answers, then it works better to tell the engine
that is what you want. For your example:

syms x real
solve('abs(x) = x^2')

ans =

   0
   1
  -1

Alan Weiss
MATLAB mathematical toolbox documentation

> Hi, I believe the reason MATLAB is having a hard time is that the MuPAD
> engine assumes by default that symbolic variables are complex. If you
> want to look for real answers, then it works better to tell the engine
> that is what you want. For your example:
>
> syms x real
> solve('abs(x) = x^2')
>
> ans =
>
> 0
> 1
> -1
>
> Alan Weiss
> MATLAB mathematical toolbox documentation

Didn't Maple assume variables to be complex, too?

Husam Aldahiyat wrote:
> Put MATLAB 2007b in a .dll and call it in MATLAB 2008b to solve said problem.

The 2007b symbolic toolbox is not eligible for deployment; and it would be
against the Terms of Use to create a dll that essentially just provided
command line access to Matlab without "added value". You can read the Terms of Use
for yourself by going to the very bottom of any of the right-hand-side pages in
the Matlab documentation viewer and clicking there on the Terms of Use link.
 
> Seriously though, calling out MuPad shortcomings is old news now.

I, for one, was unaware that it broke down in such simple calculations.
It -appears- to be defective to the point where it should be recalled; or
free upgrades made available (for several generations of the toolbox --
and several generations of Matlab too if the interface between the
two is faulty) until it meets "implied merchantability" tests.


Do you use any of the toolboxes? The Image Processing Toolbox, say? If you
found that it produced absolutely completely wrong answers on simple cases
when previously it had been thought it only broke on much more complicated cases,
would you be shrugging and saying "We're tired of hearing about this" ?



--
.signature note: I am now avoiding replying to unclear or ambiguous postings.
Please review questions before posting them. Be specific. Use examples of what you mean,
of what you don't mean. Specify boundary conditions, and data classes and value
relationships -- what if we scrambled your data or used -Inf, NaN, or complex(rand,rand)?

Walter Roberson wrote in message .
> > Put MATLAB 2007b in a .dll and call it in MATLAB 2008b to solve said problem.
>
> The 2007b symbolic toolbox is not eligible for deployment; and it would be
> against the Terms of Use to create a dll that essentially just provided
> command line access to Matlab without "added value". You can read the Terms of Use
> for yourself by going to the very bottom of any of the right-hand-side pages in
> the Matlab documentation viewer and clicking there on the Terms of Use link.
>

I wasn't being serious. Wasn't it obvious by the "seriously though" that followed? Putting MATLAB in a .dll and calling it out in full in a future version is a funny thought though. Makes the mind boggle hehe.

> > Seriously though, calling out MuPad shortcomings is old news now.
>
> I, for one, was unaware that it broke down in such simple calculations.
> It -appears- to be defective to the point where it should be recalled; or
> free upgrades made available (for several generations of the toolbox --
> and several generations of Matlab too if the interface between the
> two is faulty) until it meets "implied merchantability" tests.
>
>
> Do you use any of the toolboxes? The Image Processing Toolbox, say? If you
> found that it produced absolutely completely wrong answers on simple cases
> when previously it had been thought it only broke on much more complicated cases,
> would you be shrugging and saying "We're tired of hearing about this" ?
>

Breaking down in the equation shown is not more serious than its breaking down in the other articles and posts from before. It's doubtful that the developers behind this new feature didn't test it to a competent degree, and now it seems it's not a matter of giving up on MuPad, but rather learning to get accustomed to its syntax restrictions.

Some guy answered the question and solved the problem anyway. Just declare it real, what's hard about that? If Symbolic toolbox 1 couldn't solve this without declaring it real no one would be complaining.

Don't know about everyone else, but the problem presented in this thread is far less severe than this

int(’arctan(x)/x^(3/2)’,0,1)
2008b: Warning: Explicit integral could not be found.

Which was mentioned ages ago.