I am not familiar with the details of the bug that Alejandro mentioned. Since I never use 2d input, it hasn't affected me. But I think that there may have been a syntax change since Maple 12 such that if...then...elif...else...end if statements are now allowed immediately after the operator-defining arrow -> (and are the only statements allowed there). For the older Maple, the operator form `if`(...) may be required. So try this:

DetAn:= (n::nonnegint)-> LinearAlgebra:-Determinant(
     Matrix(
          n, n,
          (i,j)->
               `if`(
                    j >= i and (j-i)::even,
                    (j-i+1)*(j-1)!/(i-1)!*a(j-i+1)*x,
                    `if`(i-j = 1, -1, 0)
                )               
     )
):

It's unfortunate, because for a compound conditional, I think that the statement form is easier to read.

I am not familiar with the details of the bug that Alejandro mentioned. Since I never use 2d input, it hasn't affected me. But I think that there may have been a syntax change since Maple 12 such that if...then...elif...else...end if statements are now allowed immediately after the operator-defining arrow -> (and are the only statements allowed there). For the older Maple, the operator form `if`(...) may be required. So try this:

DetAn:= (n::nonnegint)-> LinearAlgebra:-Determinant(
     Matrix(
          n, n,
          (i,j)->
               `if`(
                    j >= i and (j-i)::even,
                    (j-i+1)*(j-1)!/(i-1)!*a(j-i+1)*x,
                    `if`(i-j = 1, -1, 0)
                )               
     )
):

It's unfortunate, because for a compound conditional, I think that the statement form is easier to read.

@Markiyan Hirnyk Numeric solution is almost always simpler to achieve. But more can be known about the function by symbolic solution when the answer is simple. Also, this symbolic solution can be numerically evaluated to a far higher accuracy than a dsolve(..., numeric). I think that a piecewise elementary function is simple enough.

Rather than getting constants of integration, I used the same initial conditions that Markiyan used in his numeric solution.

The last line got cut off by the MaplePrimes editor, but you can see it in the worksheet.

Download piecewisedsolve.mw

Wow, I've looked this over for about 30 minutes, and tried every trick I could to analyze it, and I'm stumped.

Setting Digits:= 15, all plots are identical with very smooth convergence to 0.06188 at z = 0. Since that is my default value of Digits, I didn't notice the numeric instability until Markiyan posted his plot.

Setting Digits:= 15, all plots are identical with very smooth convergence to 0.06188 at z = 0. Since that is my default value of Digits, I didn't notice the numeric instability until Markiyan posted his plot.

I know that you said that you "do not want an analytical solution", but would your opinion change if I told you that an analytic solution was fairly simple, and fairly easy to obtain?

I am sure that what you want to do is possible, but I am not sure about the details of what you want. Could you describe it better? Does f1 call f2, or does f2 call f1? Why is the (1,2) repeated in the call to f2? Is either procedure written already?

@Adri van der Meer I had considered the one-to-many situation. I was thinking that solve should detect the one-to-one case and remove the brackets. But maybe not; perhaps they should remain because they will be expected. So here's a way to remove the brackets that can deal with either situation: just replace unapply with op@unapply.

f:= x-> piecewise(x<1, x, x-1): 
solve(f(x)=y, x): 
g:= op@unapply(%, y):

g(2);
                               3
g(1/2);
                              3  1
                              -, -
                              2  2

@Adri van der Meer I had considered the one-to-many situation. I was thinking that solve should detect the one-to-one case and remove the brackets. But maybe not; perhaps they should remain because they will be expected. So here's a way to remove the brackets that can deal with either situation: just replace unapply with op@unapply.

f:= x-> piecewise(x<1, x, x-1): 
solve(f(x)=y, x): 
g:= op@unapply(%, y):

g(2);
                               3
g(1/2);
                              3  1
                              -, -
                              2  2

Please don't make the titles of your Questions so long. A fine title for your Question would've been "How to neglect 1/c^n terms, n > 2?". You tend to put the entire body of your Question in the title.

@Markiyan Hirnyk I only meant for my answer to be one additional step inserted into the process that Adri already had, namely using unapply. I'm sure that that would've been obvious to Adri.

@Markiyan Hirnyk I only meant for my answer to be one additional step inserted into the process that Adri already had, namely using unapply. I'm sure that that would've been obvious to Adri.

Your Question seems incomplete. Did you mean to say more?

How about some commentary to accompany your solution? What is the significance of the 0.64 and 73? Why do the solutions only have 2 or 3 digits?

Your C is essentially -infinity, putting the sum to 0 and thereby making B irrelevant. So the solution curve is essentially a straight line through the origin, which looks like a decent fit on a plot.

I be interested to see how DataFit performs with sample data actually produced by the function.