@williamov I did not intend for the procedure DetAn to be used in a summation! I wrote it so that you could look at the determinants. It can only be called with specified integer arguments. You cannot "convert" a symbol into an integer just by using a convert command!

@Alejandro Jakubi Thank you for bringing this shocking and sad situation to my attention. Unfortunately, I am seeing more and longer sections of code written in the 2d input and it is more difficult to read and to debug.

@Alejandro Jakubi Thank you for bringing this shocking and sad situation to my attention. Unfortunately, I am seeing more and longer sections of code written in the 2d input and it is more difficult to read and to debug.

@casperyc Sorry that my little joke about the real reals was not understood. What I meant was that you should generate random floating-point numbers using the full value of Digits that you're working with. That way you're sampling from an essentially infinite set of numbers, rather than the 601 that you get from rand(-300..300)/100. You can make a generator procedure for a list of 4 floats in -3..3 like this:

myRand:= RandomTools:-Generate(
     list(float(range= -3..3, digits= 15), 4),
     makeproc
):
myRand();

[-1.96641365834694, 0.97863816019558, 1.64810779924759, 2.15154588529516]

You are correct that the (true) rank of a numeric matrix cannot be greater than the rank of the symbolic matrix from which it is derived. Any apparent counter-example must be due to an accumulation of round-off errors in the numeric rank algorithm. LinearAlgebra:-Rank uses a singular value decomposition for float-point matrices. If you find another example of such a Matrix, I'd be very interested in looking at its singular values.

@casperyc Sorry that my little joke about the real reals was not understood. What I meant was that you should generate random floating-point numbers using the full value of Digits that you're working with. That way you're sampling from an essentially infinite set of numbers, rather than the 601 that you get from rand(-300..300)/100. You can make a generator procedure for a list of 4 floats in -3..3 like this:

myRand:= RandomTools:-Generate(
     list(float(range= -3..3, digits= 15), 4),
     makeproc
):
myRand();

[-1.96641365834694, 0.97863816019558, 1.64810779924759, 2.15154588529516]

You are correct that the (true) rank of a numeric matrix cannot be greater than the rank of the symbolic matrix from which it is derived. Any apparent counter-example must be due to an accumulation of round-off errors in the numeric rank algorithm. LinearAlgebra:-Rank uses a singular value decomposition for float-point matrices. If you find another example of such a Matrix, I'd be very interested in looking at its singular values.

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