@Markiyan Hirnyk Well, it depends on how you would like the complex numbers to be represented in Excel. What I did before was only exporting Real and Imaginary parts as numbers and the whole complex numbers as a text (or string)!

Thanks to your comment I looked more into it and found out that Excel has a constructor for complex numbers and several functions for computing with complex numbers (at least MS Excel 2007). So another possibility can be:

A := LinearAlgebra[RandomMatrix](2, 4, generator = rand(0 .. 5)+I*rand(-3 .. 5));

complex_numbers := map(x -> cat("=Complex(", Re(x), ";", Im(x), ")"), A);

with(ExcelTools):
Export(complex_numbers, "D:/example2.xls", "Complex numbers", "A2");

Which results in this Excel file:

Now, there are really complex numbers (how Excel takes it), but it should be evaluated. I can evaluate only cell after cell (which is so impractical)  to get:

Excel (at least the 2007 version) can perform some computations with those numbers, but it is nothing "great". When I try e.g. "=IMPOWER("i";2)", which should be equal to -1 (=i^2), I get:

It is an upgrade. I installed it in May as 15.00 version and then upgraded it. But I also have some other (older) versions of Maple like Maple 12 or 13 and it behaves the same way like it does in Maple 15.01 (Standard OK, Classic doesn't work).

This is the file: optimization.mws

It is an upgrade. I installed it in May as 15.00 version and then upgraded it. But I also have some other (older) versions of Maple like Maple 12 or 13 and it behaves the same way like it does in Maple 15.01 (Standard OK, Classic doesn't work).

This is the file: optimization.mws

You can use Kitonum's solution of the previous problem. It is very similar. Now you only replace the constraints f(1)>0, max(S)<1 instead of the previous f(0)>0, min(S)>0 in the solve command.

This thread is really long (and badly arranged)...

You can use Kitonum's solution of the previous problem. It is very similar. Now you only replace the constraints f(1)>0, max(S)<1 instead of the previous f(0)>0, min(S)>0 in the solve command.

This thread is really long (and badly arranged)...

@Markiyan Hirnyk The problem was to find only the positive solutions.

@Markiyan Hirnyk The problem was to find only the positive solutions.

@Danik You can see clearly what is happening there when you explore a little the sol function. Having the default settings (Digits=10), the sol looks like this:

Just at first sight you see the numbers there contain really many digits. Let's simplify it a little and take this expression only:

ex := 569410034800000000/(-20000000000000000000+2026423673318357569*Pi^2);

When you evaluate the denominator only (for different precisions), you e.g. get:

evalf(denom(ex));

evalf(denom(ex), 15);

The difference is caused by different rounding of its second part. Two very similar numbers in the denominator are subtracted. First nine digits "disappear" and the error which was previously only somewhere around the tenth digit (for Digits=10) now moves very up (to the first digit). Just look at how that second term of the denom(ex) looks like for different precisions:

evalf(2026423673318357569*Pi^2);

evalf(2026423673318357569*Pi^2, 15);

That is why you have to increase the value of Digits variable to maintain acceptable accuracy.

@Danik You can see clearly what is happening there when you explore a little the sol function. Having the default settings (Digits=10), the sol looks like this:

Just at first sight you see the numbers there contain really many digits. Let's simplify it a little and take this expression only:

ex := 569410034800000000/(-20000000000000000000+2026423673318357569*Pi^2);

When you evaluate the denominator only (for different precisions), you e.g. get:

evalf(denom(ex));

evalf(denom(ex), 15);

The difference is caused by different rounding of its second part. Two very similar numbers in the denominator are subtracted. First nine digits "disappear" and the error which was previously only somewhere around the tenth digit (for Digits=10) now moves very up (to the first digit). Just look at how that second term of the denom(ex) looks like for different precisions:

evalf(2026423673318357569*Pi^2);

evalf(2026423673318357569*Pi^2, 15);

That is why you have to increase the value of Digits variable to maintain acceptable accuracy.

@Danik You have to increase the Digits variable just before the plot command. Look at the sol function for different precisions. The more digits you use for computing the sol function, the higher precision is needed afterwards.

@Danik You have to increase the Digits variable just before the plot command. Look at the sol function for different precisions. The more digits you use for computing the sol function, the higher precision is needed afterwards.

I'm glad it helped.

I'm glad it helped.

If you want to bound somehow the error of the numerical solution, you should read ?dsolve/numeric/Error_Control.

@marram When I type

infolevel['rsolve'] := 2:
rsolve({c*(n+beta)*P(n+1)/(-1+c)+(c*(x+beta)/(1-c)-x)*P(n)+n*P(n-1)/(-1+c) = 0, P(0) = 1}, P(n));

I get

rsolve: solving single equation recurrence
rsolve/single/process: using LREtools
LREtools/hypergeomsols: entering with RESol({(n+1)*P(n)+(-2*c*x-c*beta+x)*P(n+1)+(c*n+c+c*beta)*P(n+2) = 0} {P(n)} {P(0) = P(0) P(1) = P(1)} INFO)
LREtools/hypergeomsols: Warning: no hypergeometric solutions found
rsolve/single/process: trying LREtools[HypergeometricTerm]
LREtools/hypergeomsols: entering with RESol({(n+1)*P(n)+(-2*c*x-c*beta+x)*P(n+1)+(c*n+c+c*beta)*P(n+2) = 0} {P(n)} {P(0) = P(0) P(1) = P(1)} INFO)
LREtools/hypergeomsols: Warning: no hypergeometric solutions found
      / /
rsolve|{
      \ \

  c (n + beta) P(n + 1)   /c (x + beta)    \        n P(n - 1)      
  --------------------- + |------------ - x| P(n) + ---------- = 0,
         -1 + c           \   1 - c        /          -1 + c        

          \       \
  P(0) = 1 }, P(n)|
          /       /

Which version of Maple do you use?