@abdulganiy The ability of display to handle legend must've changed recently. Here's a version of Tom's plot that should work for you:

restart:
B:= [
    [ 
        600*2^~[$0..4]+~1,    
        [2.87E-19, 7.94E-21, 7.94E-23, 1.03E-24, 5.91E-26]
    ],
    [
        2000*2^~[$0..4]+~1, 
        [3.30E-2, 5.37E-4, 8.47E-6, 1.33E-7, 2.08E-9]
    ],
    [
        [183, 365, 728, 1476, 2910],      
        [4.58E0, 7.54E-8, 2.20E-11, 4.95E-14, 9.15E-15]
    ],
    [
        [1621, 3020, 6166, 12022],      
        [2.95E-3, 8.51E-6, 3.39E-8, 2.51E-10]
    ]
]:
plot(
    (`[]`~@op@(log[10]~)~)~(B),
    legend= ["BFFM", "BNM", "BHM", "ARKN"],
    color= [red, gold, blue, black],
    symbolsize= 15,
    axes= framed, 
    symbol= [box, circle, solidbox, solidcircle],
    style= "pointline",
    labels= (typeset@log__10)~([NFE, `Max Err`])
);

@Jean-Michel Collard 

I have considered everything that you've posted to be appropriate material for MaplePrimes. However, you consistently (well over half the time) put your contributions in the wrong places. When I have suggested to you the correct placement (without any tone of reprimand), you have responded with stubborness and refusal. I would call that "roughness".

This is not a "chat room". It's a repository of technical and scientific information whose contributions will be used for reference for many years to come. Correct placement of the material helps with that.

@Carl Love And here is how you would correct the syntax on what you were trying to do. But note that this is not the preferred way to integrate a numeric ODE solution:

g:= 9.81:  h:= 0.1:  rinit:= 0.1: tinit:= 5:
dsysA:= {
    diff(r(s), s) = sqrt((g*r(s) + h)^2 - 1 + 1/r(s)),
    r(0) = rinit
}:
dsnA:= dsolve(dsysA, numeric, abserr= 1e-6):
rA:= s-> `if`(s::numeric, eval(r(:-s), dsnA(s)), 'procname'(args)):
rA(0.1);
                       0.429604957845729

t:= s-> tinit + 
    int(p-> (g*rA(p) + h)/(1 - 1/rA(p)), 0..s, numeric, epsilon= 1e-6)
:
t(0.1);
                        4.89144148361160

@Jean-Michel Collard I don't have direct access to users' email addresses. But any user here can contact another user via email by using the More => Contact Author menu in the bottom right corner of any message. I just used this method to send you one, which you can reply to via normal email.

If you send me an email, there's a good chance that I'll do one of these things:

1. Say that the material should be discussed on MaplePrimes.
2. Edit the material such that it'd be appropriate for MaplePrimes and return it to you so that you can post it.
3. Edit the material, return it, and suggest that I post it.

As the second-highest-ranking Moderator here, I request that you respect my decision on what material is appropriate for MaplePrimes and whether it should be added to an existing thread or made into a new thread.

@tomleslie My guess is that those two numbers were deemed outliers and not wanted for this plot.

It is obvious to me that whoever designed the syntax of animate intended this syntax for the plot under discussion:

plots:-animate(plots:-arrow, [<cos(t), sin(t)>], t= 0..2*Pi);

This solves the problem in the same manner as Robert Lopez's Answer. There is no difference between arrow and PlotVector with respect to this premature evaluation issue. There are numerous good reasons why one of these plot commands may be preferred over the other, but premature evaluation is not one of those reasons.

Maple offers many ways to change the order of evaluation of expressions. Among these ways, the unevaluation quotes are usually the most difficult to use and to understand. Although it's not always possible to avoid their usage, I think that it's best to avoid them when possible. In this case, the method for avoiding them has been intentionally built into the syntax of animate.

The failure to display the worksheet in the Question is due to a bug in MaplePrimes. It's not your fault, there's no neec to be sorry. The bug only affects the display of the worksheet, not its ability to be downloaded.

@Jean-Michel Collard You asked:

• Edgardo: Any idea to implement 2-spinors in the Physics package?

You should ask that as a new Question thread.

@Jean-Michel Collard You wrote:

• What you wrote is the link to all my "questions". With that I can't reply to Carl.

I realize that you've already found it and made your Reply; however, for future reference, from that link to your Questions you can click on the title line of any individual Question and that'll take you to that Question with all of its Answers and Replies. So Kitonum's original link works also.

@Prakash J "...for the curve is convergence" doesn't quite make sense in English. Do you mean initial conditions such that the curve has a horizontal asymptote, i.e., such that its limit at infinity exists and is finite?

@Robert Jantzen To attach a worksheet (or a few other file types), use the thick green up arrow on the toolbar. Worksheets cannot currently be displayed inline, but they can be attached for downloading.

I guess that you intended to attach a worksheet but then didn't do it.

@nm 

The keyword function used as a type in your procedure's header is too restrictive. Maple's definition of function as a type is perhaps idiosyncratic (i.e., specific to Maple in a way that deviates from commonly used definitions), so having made this mistake is quite understandable. Your example cos(x*y) is a function but cos(x*y) + sin(x*y) is not. See ?type,function. If you change function to algebraic, then it's fine. This type, algebraic, is also defined idiosyncratically, because even transcendental functions^[*1] such as cos(x*y) are considered algebraic by Maple (but not in standard mathematical language, where transcendental and algebraic are dichotomous).

An unrelated recommendation is that you change vars::list to vars::list(name).

[*1] Note that I intentionally used function here in one of its standard mathematical usages, just to show the contrast. In even another usage---in a generic computer-science context---function often means essentially the same thing as what Maple calls a procedure.

@vv I don't know why you've attached this Reply specifically to my Answer.

It's impossible to properly understand what's going on here without addressing quantification.  For example, the command is applies universal quantification to all variables. It's companion command coulditbe applies existential quantification. If you had replaced is with coulditbe, then you'd have true implies false.

Perhaps you do not realize that the OP has extensive CAS experience (30 years using Mathematica, 29 years using Maple, 16 years on MaplePrimes). He is not a newbie who has simply stumbled upon this anomaly and is looking for a simple explanation. I believe that he wants a broad discussion of the formalism.

Almost certainly your problem is due to a programming error that'd be easy to correct if we could see the code. It's unlikely that it's due to an actual memory limitation, and, even if it is, it's likely that we could figure out a way around it.

Perhaps it would be easier for you to simply present here the combinatorial problem rather than the code.