symbolic solver strikes again!

Someone please tell me why this doesn't work.

I have used symbolic solver many times and every time i do i end up wishing i pulled out my ti89 and been done with it. I waste more time messing with this then its worth

Example code to confirm it works

syms x
eqn = sin(x) == 1;
%%just for confirmation
eqn

   eqn =

sin(x) == 1

   solx = solve(eqn,x)

    solx =

    pi/2

Very simple obviously

Now again

equation = exp(x/.2968)/exp(227.1692/.2968) == 9/2;
equation

equation =

0 == 9/2

How is my equation now

0 == 9/2

??????????

Also another version i have tried that used to work all the time and no longer does

syms x
solve(900/200 == exp(x/.2968)/exp(227.1692/.2968) ,x)

ans =

Empty sym: 0-by-1

Obviously the answer is now a 0X1 matrix

Answer 1

[Walter Roberson]

Remember that floating point expressions are calculated in floating point before the expression is sent to the symbolic engine, and that at the time you send to the symbolic engine all remaining floating point values are converted to rational.

If you are more careful about the conversion then you can get a solution:

Q = @(v) sym(v);    %converts value to symbolic rational number
solve(Q(900)/Q(200) == exp(x/Q(.2968))/exp(Q(227.1692)/Q(.2968)) ,x)

ans =
(371*log((9*exp(47127391862749375/61572651155456))/2))/1250

you can then simplify(ans) to get something more compact.

In particular you are getting floating point overflow when you calculate exp(227.1692/.2968) in floating point.

In the first equation, you are dividing by that inf. exp(x/.2968) is treated as "some non-zero value" (x would have to be -inf for the exp() to become 0), and a non-zero value divided by inf is 0 . The left side of your first equation thus becomes 0.

My rule of thumb is to never use floating point quantities in a symbolic expression; I always convert them to rational on input, to avoid these kinds of numeric problems.

[Robert]

i have no clue what your talking about. So my ti89 solved this in .5 seconds with no hassle at all and matlab can't do it without a bunch of bs is what your saying. ok got it. typical matlab nonsense

[John D'Errico]

Hey, you are the one who apparently has no interest in learning.

[Robert]

no interest in learning? wow how did you get that assumption out of what i said. very strange. If i told you the sky was red would you tell me i have no interest in the air pressure of the tires of your car? thats how obscure and pointless your comment is. Who said i had no interest in learning. I said i have no clue what you mean and expressed my hatred for the foolishness of matlab. My thousand dollar computer program is stumped when my $150 calculator has no problem solving this

[Walter Roberson]

Your TI89 is always operating in symbolic mode.

MATLAB itself does not operate in symbolic mode. When it goes to execute exp(227.1692/.2968) it parses the 227.1692 as an IEEE 754 Double Precision number, and it parses .2968 as an IEEE 754 Double Precision number, and it does IEEE 754 standard division between those double precision floating point numbers, getting out an IEEE 754 standard double precision number. Then it passes that to the IEEE 754 standard exp() operator. That is exp(765.3948787061993925817660056054592132568359375) . However, IEEE 754 standard double precision numbers have a maximum representable value that is approximately 1.79769313486232e+308 (which is about 2^1024), and the result of that exp() would exceed that maximum representable value, so as per IEEE 754, the result of the exp() is set to the special value inf (positive infinity). The result of the exponential would be approximately 2.551363270448470*10^332. IEEE 754 double precision numbers are fixed at 64 bits long, including sign, exponent, and mantissa, so there is no room for "expansion" if the calculation needs larger numbers.

Your TI89 uses software numbers that allocate more memory if more precision is required. I did not find the limits in my research a moment ago, but I did find evidence that the TI89 can support at least 360 digits. Software numbers are not routinely used in MATLAB because software numbers are slower.

MATLAB has a Symbolic Toolbox that implements software numbers. However, that toolbox is not invoked for all calculations just because it is installed: instead, MATLAB only invokes the toolbox when it finds a symbolic expression. If you have an expression such as

   syms x
   x + 5/3

then the 5/3 would be calculated numerically (in double precision) yielding 1.6666666666666667406815349750104360282421112060546875 and then the Symbolic Toolbox would be invoked to calculate x plus that. You can force a number to be converted to symbolic by passing it to sym:

   x + sym(5)/3

This would call sym(5) returning a software 5, and then symbolic toolbox would be called to divide the software 5 by the double precision 3, returning a software result that is the fraction 5/3 and then the symbolic toolbox would be called to add symbolic x and the software 5/3 .

If you want to work with a symbolic environment then you can give the command

mupad

which will then open up a window that communicates directly with the symbolic engine (which is named MuPAD) where the calculations are not interpreted as IEEE 754 numbers and instead are calculated as software numbers.

mupad has its own limitations -- it will not handle more than 536870913 decimal digits of calculations for example. (Yes, I have hit those limits and needed more!)

[Chris Gorden]

This is an excellent explanation W.R. and thank you for taking the time to describe the situation in such detail. I believe that I originally came across this thread a few months to a year a ago, when I ran into similar issues using Symbolics in Live Scripts.

I've never actually used MuPad because when you ener the command in 2019b+ a pop-up informs you that Live Scripts will ultimately replace Mupad. I really enjoy Live Script but it is definitely not a purely symbolic environment, as you have described Mupad. It seems that all of the additional precautions that you describe are still necessary in the Live Script.

So my question to you, or anyone paying attention to this somewhat dated thread: Is there a way to get a Live Script to be a symbolic environment in the way that MuPad apparently functioned?

While I know this is not currently the case, my dream solution would be something like a "format symbolic" command.

[Walter Roberson]

@Chris Gorden

Unfortunately, no. About the closest you can get is to str2sym() every expression.