@samiyare 

So sorry. There was one character missing from the code. The constant in the ode should be _C, not C. I corrected the code in the Answer (and added some explanation). Please download again and try it again.

@Alex Smith Okay, I understand you. I do suppose that (1) the values at the two interior points are to be determined by the solution, that (2) any putative solution is differentiable on the interval 0..0.5 to the highest order required by the problem, and that (3) a numeric solution suffices. I suppose that you could say in the language of "posedness" that I suppose any discrete and reasonable thing required to make the problem well-posed.

@Alex Smith Okay, I understand you. I do suppose that (1) the values at the two interior points are to be determined by the solution, that (2) any putative solution is differentiable on the interval 0..0.5 to the highest order required by the problem, and that (3) a numeric solution suffices. I suppose that you could say in the language of "posedness" that I suppose any discrete and reasonable thing required to make the problem well-posed.

The fact that there's an integral does not pose any significant problem per se. The integral in this BVP does not depend on the independent variable, eta. In other words, given any putative solution to the BVP, we can compute the value of the integral. So, this problem is very similar to your other BVP from today, "solve an especial ode", with the integral playing the role of the 2*u(.25)+u(.16) from that BVP. So the same solution technique should work, in principle:

1. Replace the integral with a variable
2. Write a procedure whose input is a numeric value of that variable
3. Have the procedure apply dsolve at that numeric value
4. Compute the integral using that dsolve solution (by using `evalf/Int` with the integrand as a procedure)
5. Return the difference between the integral and the input value
6. Apply fsolve to the procedure.

But the dsolve is not converging for any value of the integral close to the (or a) solution, which I'm guessing is between -0.5 and 0. I've tried using a continuation parameter (see ?dsolve,numeric,BVP ) in about a dozen different places in the system, with no luck.

Perhaps someone who knows more than I do about continuation parameters can take a look at this. I emphasize that the integral is not the problem; the convergence issues arise with the integral replaced by a constant.

@phil76600

The reason that it is slow is that an fsolve command is used for every point plotted. In other words, in order to evaluate the implicit function numerically at a value of Vb, I solve equation eq numerically for pH. (Do you understand that?) From the gaps that you're getting, I guess that the fsolve may be having trouble converging for some points. What version of Maple are you using? I am not having that trouble in Maple 17. If it really matters, it may be possible to adjust some options and fill those gaps. Are you getting gaps in the plot of the primary also? I can't figure out a reason that you would only get gaps in the derivative. Both the primary and the derivative are applying fsolve to the same equation.

You can improve the speed by reducing the value of numpoints in the plots. The default value is about 200.

You asked:

`f'`:= (-D[2]/D[1])(F) @ (V__b-> (f(V__b),V__b)):

Why is 'f' necessary.

Are you asking why the quotes are necessary? If that's what you're asking: I wanted to name the derivative f ', that being one of the normal representations of a derivative and the one that you used. But f ' is not a valid name in Maple because it contains a special character. However, anything at all can be made into a valid name by enclosing it in back quotes (``). Does that answer your question?

You asked:

And what is that @ in this line ?

The @ is how one expresses functional composition. In other words, if h(x) = f(g(x)), then h = f@g. I did it this way to separate the symbolic computation (the left side) and the numeric computation (the right side). That way the symbolic differentiation is only done one time total, and the fsolve is only done one time for each point. Does that answer your question?

@phil76600

The reason that it is slow is that an fsolve command is used for every point plotted. In other words, in order to evaluate the implicit function numerically at a value of Vb, I solve equation eq numerically for pH. (Do you understand that?) From the gaps that you're getting, I guess that the fsolve may be having trouble converging for some points. What version of Maple are you using? I am not having that trouble in Maple 17. If it really matters, it may be possible to adjust some options and fill those gaps. Are you getting gaps in the plot of the primary also? I can't figure out a reason that you would only get gaps in the derivative. Both the primary and the derivative are applying fsolve to the same equation.

You can improve the speed by reducing the value of numpoints in the plots. The default value is about 200.

You asked:

`f'`:= (-D[2]/D[1])(F) @ (V__b-> (f(V__b),V__b)):

Why is 'f' necessary.

Are you asking why the quotes are necessary? If that's what you're asking: I wanted to name the derivative f ', that being one of the normal representations of a derivative and the one that you used. But f ' is not a valid name in Maple because it contains a special character. However, anything at all can be made into a valid name by enclosing it in back quotes (``). Does that answer your question?

You asked:

And what is that @ in this line ?

The @ is how one expresses functional composition. In other words, if h(x) = f(g(x)), then h = f@g. I did it this way to separate the symbolic computation (the left side) and the numeric computation (the right side). That way the symbolic differentiation is only done one time total, and the fsolve is only done one time for each point. Does that answer your question?

The second ODE contains a constant phi[0]. Unless you say otherwise, I am going to assume that that should be phi(0), which equals 1 according to your boundary conditions.

In the Maplesoft Blog Posts sections of this forum, look at the most recent Post, entitled "Introducing the Maple IDE". That product will let you step through the code line by line in a separate window.

Your expression has no inequality sign.

Your values for n = 8, 9, and 23 are obviousy wrong. And why do some have only 9 digits?

Considering how difficult this is to compute, I think that you should post your Mathematica code so that it can be verified.

Recursively, we have a(n) = n^a(n-1), a(1)=1. And we're displaying a(n) mod 10^10.

I don't know how to use Maple to compute this for n > 6. Anyone have an idea? How does Mathematica do it? How do you reduce the exponent to a computable value in modular arithmetic? In other words, we want to compute

(A &^ B) mod 10^10

where B itself is too large to compute. Is there some way to reduce B using the modulus? Surely Mathematica cannot compute a(49) directly. Surely that number has more bits in its representation than there are electrons in the Universe.

But there is a pattern to the moduli of a(n) based on the last digit of n.

Marvin Ray Burns wrote:

I've been playing around with power towers and thought my latest might be interesting enough to post.

It's only interesting to me if we discuss algorithms for computing such things.

Do you see that as being substantially different from having a single worksheet with all the code in one execution group?

@tuGUTS Yes, you can add initial and boundary conditions. These will, if they work at all, remove some or all of the arbitrary functions and constants from the solution. I also don't know what would be appropriate initial and boundary conditions for this PDE. But see ?pdsolve for numerous examples.

@tuGUTS Yes, you can add initial and boundary conditions. These will, if they work at all, remove some or all of the arbitrary functions and constants from the solution. I also don't know what would be appropriate initial and boundary conditions for this PDE. But see ?pdsolve for numerous examples.

You equations are effectively a system of ordinary differential equation. Try changing alpha(r,t) to alpha(r) and then using dsolve. (Although I wouldn't be surprised if pdsolve had already tried that.) It might help to make assumptions on c and kappa such as assume(c>0, kappa>0).

I would try these things myself, but I don't feel like typing in your equations. Please post them in plaintext or upload a worksheet.