@Markiyan Hirnyk Thanks for finding it. So, to answer the original Question, f(x) = (2*x)!/x!/(x+1)!  Maple can verify this solution, even though rsolve won't find it:

f:= x-> (2*x)!/x!/(x+1)!:
g:= x-> sum(f(k)*(f(x-k-1), k= 0..x-1):
simplify(f(x) - g(x));

                                   0

And with this form, the conjectures are obvious.

@Markiyan Hirnyk Thanks for finding it. So, to answer the original Question, f(x) = (2*x)!/x!/(x+1)!  Maple can verify this solution, even though rsolve won't find it:

f:= x-> (2*x)!/x!/(x+1)!:
g:= x-> sum(f(k)*(f(x-k-1), k= 0..x-1):
simplify(f(x) - g(x));

                                   0

And with this form, the conjectures are obvious.

The phenomenon that you describe is not strange to me. The fsolve most likely failed because it could not guarantee the desired amount of precision. Unlike solve, fsolve does not try to eliminate variables. You discovered a way to eliminate three of the variables with solve, leaving a single equation for fsolve. It is much easier to guarantee the precision numerically solving a single equation.

@Sergio Parreiras In your large expression, the thing superficially appears to be a common denominator is theta - 1. That is not a denominator of the overall expression; it a denominator of exponents. Since the exponents are exponents of terms in a sum, there's no obvious way they can be simplified.

@Sergio Parreiras In your large expression, the thing superficially appears to be a common denominator is theta - 1. That is not a denominator of the overall expression; it a denominator of exponents. Since the exponents are exponents of terms in a sum, there's no obvious way they can be simplified.

@Stavros Okay. I'd prefer if you post any followup questions right here, or in a new Question if they can stand alone.

@Stavros Okay. I'd prefer if you post any followup questions right here, or in a new Question if they can stand alone.

@acer I thought that someone might catch that, thinking that I meant "assume" in the mathematical sense. I regret not editing it. What I meant was "In order for Maple to perform the expansion, it is necessary to assume that they (the factors) are positive." (Hoping that you understand the distinction that I make with boldface.) But you do bring up two other possibilities for assumptions that I hadn't considered: If you assume that a is integer, or that all factors except for one are positive, it will also perform the expansion:

expand((A*B*C)^a) assuming a::integer;

expand((A*B*C)^a) assuming A > 0, B > 0;

@acer I thought that someone might catch that, thinking that I meant "assume" in the mathematical sense. I regret not editing it. What I meant was "In order for Maple to perform the expansion, it is necessary to assume that they (the factors) are positive." (Hoping that you understand the distinction that I make with boldface.) But you do bring up two other possibilities for assumptions that I hadn't considered: If you assume that a is integer, or that all factors except for one are positive, it will also perform the expansion:

expand((A*B*C)^a) assuming a::integer;

expand((A*B*C)^a) assuming A > 0, B > 0;

@martin_z In your Question, you said Minimize (capitalized), not minimize (lowercase). They are different commands. Anyway, you should use Optimization:-Minimize or Optimization:-LPSolve instead of simplex[minimize].

@martin_z In your Question, you said Minimize (capitalized), not minimize (lowercase). They are different commands. Anyway, you should use Optimization:-Minimize or Optimization:-LPSolve instead of simplex[minimize].

Okay, forward me the email. Use the Contact Author tool (click on "More") on the toolbar at the bottom of this Reply. Please also grant me permission to post any details that I choose to this site.

@pallav So, how do want to address the problem that the output is (most likely) too wide for your screen? Do you want each h to be directly above its AA? Do you want the output to be horizontally scrollable, or do you want line breaks? If line breaks, do you want this?

h1   h2   h3

AA1 AA2 AA3

h4   h5   h6

AA4 AA5 AA6

Or do you want the lines to break like this?

h1   h2    h3

h4   h5    h6

AA1 AA2 AA3

AA4 AA4 AA6

In addition to Sergio's excellent Answer, I wonder if there is any example where pdsolve will accept a boundary condition (BC) expressed in terms of one of the highest-order derivatives appearing in the PDE. For example, in this case, we have a BC expressed in terms of the first derivative with respect to (wrt) z, which is the highest order derivative wrt z appearing in the PDE. I can't find any example of pdsolve accepting such a BC, nor a clear statement that they are not allowed. Of course, if that is the problem, pdsolve should return an error message. But, also, it is clear in this case that there is no solution which leaves f arbitrary.

Do you need to use indexed variables? If not, change Pop[p] to Pop(p), N[p] to N(p), etc. I don't think that that's a total solution to your problem, but it will help. It is possible in Maple to take a derivative with respect to a function.