How to solve a large equation with one variable

Dear all, I need to solve a long equation. I need to read from the input files and get to know how many terms I have and the corresponding coefficients. Then I need to sum them up and set to a constant and solve it. I have tried solve, but got "Explicit solution could not be found." Can anyone help me?

The equation looks like: 10=0.01*1/(exp(129-2.5*10^5*x)/10) + 1))+ 0.02*1/(exp(150-2.5*10^5*x)/10) + 1))+ 0.02*1/(exp(200-2.5*10^5*x)/10) + 1))+ ...

Thanks a lot, Zhiting

[Walter Roberson]

In your expression, you have "+1))" several times. In each of the cases, there is no match for either of the "))" which suggests that your equation does _not_ look like what you indicate.

Can you create a smaller example and show it here? It is difficult for us to suggest how to solve an unknown equation.

[Zhiting]

sorry about the confusion.

Say something like this:

10=0.01*1/(exp(129-2.5*10^5*x) + 1)+ 0.02*1/(exp(150-2.5*10^5*x) + 1)+ ...

where 0.01, 0.02 and 129, 150 are read from input file. I may have more terms depends on the input file:

0.01 129

0.02 150

...

Answer 1

[Walter Roberson]

Expressions of this form, and which have N terms, have N solutions, some of which are almost certain to be complex. All of the solutions will be complex if the sum of the numerators (0.01, 0.02 and so on) is not at least as large as the left hand side (10 in this example.)

The solution involves solving a polynomial of degree N; there is, as usual, no general analytic solution when N is 5 or more.

However, MuPad should automatically switch to solving numerically when it cannot find the analytic solution.

If all of the terms are of the form shown, then I see no good reason for MuPad to be unable to formulate the solution, other than perhaps running out of memory or perhaps ending up with a number too big to represent. I have observed, though, that MuPad looks to be weak on finding numeric solutions to polynomials of higher order.

[Zhiting]

I need to have real root, not complex one.

If "MuPad looks to be weak on finding numeric solutions to polynomials of higher order", is there any way I could get a numerical root from MATLAB?

Actually, I am not familiar with MuPad. My m.file is as following and it takes forever:

V=load('dostest.txt');

n=10; %total number of electrons

deltaE=0.1;

T=linspace(1,1,1);

kB=1.38*10^(-23);

Mu=zeros(size(T));

E=V(:,1);

DoS=V(:,2);

N=length(E);

%elem=zeros(N,1);

x=sym('x','real');

elem=sym('elem','real');

for j=1:length(T)

elem = VPA(DoS(1)*1/(exp((E(1)-x)*1.6*10^(-19)/kB/T(j))+1)*deltaE);

for i=2:N

elem = elem + VPA(DoS(i)*1/(exp((E(i)-x)*1.6*10^(-19)/kB/T(j))+1)*deltaE);

end

elem=elem-n;

Mu(j)=solve(elem,x);

end

[Walter Roberson]

Optimize where you can.

kBr = 1.6*10^(-19)/kB;

for j = 1:length(T)

kBrT = kBr/T(j);

elem = sym(0);

for i = 1:N

elem = elem + DoS(i)/(1 + exp((E(i)-x)*kBrT));

end

elem = simple(VPA(elem / deltaE - n));

Mu(j) = double(solve(elem,x));

end

It is not clear to me that having those VPA() calls is appropriate for the problem. Also, I would do some tests to see whether simple() produces a notably simpler expression in this instance -- it might turn out just to be a waste of time for what you are doing.

It is plausible that expanding out the exp() to a division might save some time, as you can calculate exp(E*kBrT) in one go as simple numerics, and you can assign a variable that is exp(x*kBrT) at the beginning of the j loop.

I am not presently convinced that you will be able to get real-valued solutions in all cases when the DoS are nonnegative, but I would need to research that further.

[Zhiting]

I tried to simplify it as you suggested. But still got "Explicit solution could not be found".

Do you know what is the difference between solve and fzero?

[Walter Roberson]

solve() attempts to generate analytical solutions, and according to the documentation if it cannot generate analytical solutions it should try numeric solutions -- though in such a case you would get a warning about explicit solutions not found. "explicit" is the same as "analytic" for the purposes of that warning.

Nominally, solve() should return (an approximation of) an answer if there is one, but that does of course depend upon solve()'s built-in mathematical knowledge. As a user of symbolic mathematics, I would _expect_ solve() to be able to at least resolve down to a RootOf() object if polynomials are involved (as they are for the equations you are working with); but unfortunately in reading about people's difficulties with solve() in MuPad, MuPad doesn't seem know how to deal with higher orders.

I have a mental glimmer about how you might be able to generalize the problem and thus work out the polynomial whose roots you need to find; if you had a generalized form like that, it should be possible to proceed using roots() instead of symbolic equations; roots() is the numeric roots finder.