@ActiveUser To color them with specified colors, do

plot(map(ListTools:-Enumerate, LL), color= [red, blue, green]);

@mmcdara It's clear (at least to me) that the OP is referring to 3 lists of real numbers, not 3 lists of (x,y) pairs. If you're starting with lists of (x,y) pairs, then neither method guarantees that the "x-axis represents time 1, 2, 3, ...."

@vv Okay, here's an overload for all rational fractions (positive and negative):

restart:
`Psi/original`:= eval(Psi):
unprotect(Psi):
Psi:= overload([
    proc(r::fraction, $)
    option overload;
    local n, f, p, q, k;
        if r < 0 then return thisproc(-r) - 1/r - Pi*cot(Pi*r) fi;     
        (p,q):= (numer,denom)((f:= r - (n:= trunc(r))));
        simplify(
            q*add(`/`~([seq](p..(n-1)*q+p, q))) +
            2*add(cos(2*Pi*k*f)*ln(sin(Pi*k/q)), k= 1..iquo(q-1,2)) - 
            Pi/2*cot(Pi*f) - ln(2) - ln(q) - :-gamma
        )
    end proc,

    `Psi/original`
]):
protect(Psi, `Psi/original`)
:

What is the point of doing 3 identical iterations within each main-loop iteration?

After the 3rd main-loop iteration in your example, you have detectable convergence. This should be your criterion for ending the loop and returning a value.

You should compute the symbolic gradient and hessian just once. This will save a lot of cpu time.

Your code will need to be modified a little for multivariate functions. In particular, you'll want to solve a linear system with LinearAlgebra:-LinearSolve rather than divide by the hessian.

You happened to converge on the local minimum. With a different starting value, you may as well have converged on the local maximum. Optimization:-Minimize also converges on the local minimum, not the absolute minimum in the interval -2..2.

@radaar It looks to me like this algorithm cannot be easily modified for multivariate functions. The algorithm's author, Calvin, states directly in the paper's title that it's "a one-dimensional optimization algorithm".

This algorithm is intended primarily for functions that are nowhere differentiable (because they have a noise component). It is much slower than minimization algorithms intended for the usual differentiable functions.

@Gabriel samaila You can extract the numeric data from a Maple plot as a matrix or an array (or perhaps a collection of matrices or arrays if multiple pieces in the plot). Then use ExportMatrix. See its help page for information on exporting to Matlab format.

If you show the Maple command that makes the plot, I can give more details.

Or you cam use your own Maple code to generate a matrix or array and then use ExportMatrix.

There is no reasonable method that uses print. You could use fprintf to print numbers to a file, and perhaps that would be a tiny bit more efficient if done expertly, but ExportMatrix is much more convenient.

@vv Thanks. I only intended it for r > 0, as can be seen from the procedure header.

@aoakindele Sorry, but I don't know how to overcome the "matrix is singular" error from the BVP solver. My guess is that this is not caused by an input error on your part; rather, it's something inherent to the problem.

@aoakindele The total differential order (essentially, the sum of the orders of the highest-ordered derivatives of each dependent variable) of your system of ODEs is clearly 5. The number of boundary conditions must be equal to the total differential order PLUS the number of parameters that have NOT been given numeric values. You have tried to add a new boundary condition to the originally posted system:

(1+epsilon)*(D@@(F))(inf)=gamma*theta(inf)

(Note that this still contains the error that I just told you how to correct!) In order to add a new boundary condition, you need to do one of

• remove one old boundary condition,
• remove the numeric value from one parameter,
• add one new parameter.

This is a mathematically necessary limitation; it's not a limitation imposed by Maple.

@aoakindele The 2nd derivative of F at inf can be denoted (D@@2)(F)(inf).

@nm I think that you're failing to understand the contrasted logical terms necessary and sufficient. I am not trying to tell you a method that will prevent the cancellation (in other words, is sufficient to prevent the cancellation); I don't know how to prevent it. What I'm trying to tell you is that it would be impossible for there to be any cancellation-preventing method in Maple that used -(s - 1)/((-2 + s)*(s - 1)) as part of its input (in other words, it is necessary that the factored denominator not be used) because such an expression doesn't really exist in Maple. The common factor is immediately cancelled from the user input, and it's not recoverable. Likewise, the fraction 2/4 cannot exist in Maple.

@ecterrab You wrote:

• The problem with mathit is that it removes blank spaces, while in Maple, it is valid to have "symbols" with blank spaces.

Why should the Latex be crippled in order to conform with valid Maple syntax? Shouldn't the goal be to produce valid mathematical typesetting? To my mind, symbols with spaces are not valid mathematical typesetting. Thus, I wouldn't mind if the Latex command rejected them completely (with an appropriate error message).

@nm To avoid cancellation it is necessary (but, apparently, not sufficient) that the denominator be expanded. If it's not, then the cancellation will happen before the argument is passed and regardless of whether quotes are used. This is called automatic simplification, and I thought that it was what you were referring to (because you mentioned the quotes). So whatever additional steps that you need to take to prevent the cancellation, you'll still need to expand the denominator.

Never mind responding. I just figured out why dsolve didn't catch it.

@acer Please see the comment that I just posted (with the same title) to Tom's Answer. The exact same thing applies here. The primary reason that I mention it is that I don't understand how it's possible that dsolve didn't catch this.