@shakuntala I already told you that you can plot using the command

plot([seq(X2||k, k= 1..1)], 0..blt);

Did you have trouble with that? Given that you actually only have one value of k in your original loop, you can simplify that to

plot(X21, 0..blt);

But it's X21, not X2. What gives you trouble in understanding that? Are you trying to follow some printed instructions that tell you to plot X2?

Please put Replies to an Answer below that Answer, not above.

@Abdoulaye Please either present the function in a plaintext form or attach a worksheet. I can't use it in the form that you present.

@shakuntala Well, like I said, X2 by itself is meaningless. There's

X21(0);

     .332057384255589

There's no need to use print.

@Markiyan Hirnyk I redefine A and S analogously for the three-consecutive problem. We have S[n] = S[n-1] union {members of S[n-1] that it's safe to add n to, unioned with {n}} union {members of S[n-1] that it's safe to add both n and n-1 to unioned with {n, n-1}}. So A[n] = A[n-1] + A[n-2] + A[n-3]. So, the asympototic growth factor is the maximum modulus of the roots of z^3 = z^2 + z + 1, which is 1.839....

Corollary: For any positive integer n, the maximum modulus of the roots of z^n = sum(z^k, k= 0..n-1) is strictly between 1 and 2.

@Markiyan Hirnyk I'm still thinking about the case of three consecutive numbers.

@Markiyan Hirnyk See the Maple code that I just added to the Answer. You can check that every member of the sequence S contains the empty set {}. Anyway, the empty set doesn't contain n+1 either!

P.S. I think that I see what you're saying. My union~ was a poor choice of symbols, and it cannot be literally translated into Maple code. However, the actual Maple code that I added works, and produces the same sets as does your code.

@Thomas Richard I was naively answering the Question as posed. I didn't realize that this was about solving an ODE. Of course, I see that now that you've pointed it out.

Hmm, I can only find one reference to this method: Susanne Raynor, "Cubic Spline Method for Solving Second-Order Differential Equations Theory and application to the Thomas-Fermi Model for Ions", Chemical Physics, Volume 66, Issue 3, 15 April 1982, Pages 409-415.

Unfortunately, it's behind an Elsevier pay wall.

@tomleslie 

Okay, I crashed it. Setting Digits:= 10 causes it to run very slowly and crash on the fourth iteration; so, same as Tom. Using Digits:= 15, it runs pretty fast, and without error.

@digerdiga No, you totally misunderstood me. I had no doubt that it crashed for you. I was just saying that it didn't crash for me to indicate that I'm rather limited in analyzing that situation further.

Oddly enough, I have the same version as Tom, 1133417.

@digerdiga Trying your original code in Maple 2016, I don't get a crash.

@digerdiga No, it has nothing to do with the log. If you use int, then every time that you call the procedure, it will attempt to do the integral symbolically first. That attempt will fail and will be in vane---a complete waste of time.

@digerdiga No, Int is not really needed. But compare the time difference between using Int and int.

Would you please provide a derivation/justification for your second rule: h(x+y)=(x/(x+y))*h(x)+(y/(x+y))*h(y)?

When combined with the other rules, it seems to imply (1+1/z)^z = 1/(1+z) (where z = x/y), which is ridiculous because it has no h nor is it true for all z. (I did that very quickly, and mostly in my head, so I may have made a mistake.)

@DSkoog Okay, I see that the conversion from numeric to float via datatype= float is a special case of data coercion that DataSeries seem to inherit from their underlying representation as rtables. And I see that dtype is also an object member independent from the underlying rtable. I can't see yet what purpose that serves. (But I do see that the rtable may have datatype = float[8] with the corresponding dtype being simply float.)

I see that there are two roughly orthogonal operations at work here: the very common operation of converting the data and the uncommon operation changing the dtype of the container (uncommon because datatype = anything is appropriate for the vast majority of uses). The conversion of the data can be handled by mapping the appropriate conversion command. (And note that your example mapping operation, ((x)->convert(x,name))~(DS), is better done as convert~(DS, name).) The relabeling is appropriately handled by the object constructor DataSeries(...).

There's two very separate things that would bother me about the proposed command SubsDatatype: The first, and most irksome, is that the equivalent doesn't exist for rtables. If I were a new user, I'd have trouble remembering that. The second is that I, even as an old user, won't be able to remember the possible second arguments to SubsDatatype.

These are just some things to consider. I'm not totally opposed to the new command.