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.

This is a boundary-layer BVP. It can only be solved numerically, and that requires supplying numeric values for all the parameters. You also need to treat infinity as a parameter and give it a numeric value, such as 10.

I've seen this phenomenon also, but I didn't care enough about it to investigate what was causing the difference.

@nm Your Answer (both the plot and the integral) treats y=0 as one of the boundaries of the region. It is not.

Are you capable of even reading what you have posted? And do you care? The questions are obvioiusly incomplete. The right sides are cut off, and the essential information from "figure Q4a" is completely missing.

Do not check off all the product boxes. This is extremely rude, and I'm inclined to have your account flagged for deletion.

@JAMET You wrote:

• Sorry your suggestion doen't work.

Tom's Answer (vote up) doesn't contain any "suggestion", and thus it could neither be said to "work" nor not to work. The Answer explains the cause of the warning message, not how to correct it. Since the cause is fundamentally mathematical rather than being due to your coding, a bug, an anomaly (such as complex floats with infintesimal imaginary parts), or a Maple idiosyncracy (such as its rightful refusal to store nonreal numbers as real plot coordinates), this Answer is acceptable to me as an official Answer.