@rcorless The integral hides a very simple conditionally convergent alternating series (shown below) akin to an alternating harmonic series. That makes a Psi representation seem quite plausible to me.

Using assuming in the above Answer wasn't necessary; option continuous handles the assumptions.

I made that derivation a bit more automatic:

restart:
#Convert F(G(g1,gk),fk) to G(F(g1,fk),gk)
SwitchOps:= (F::And(function, function &under curry(op,1)))->
local `&<`:= rcurry(op, F);
    (&<[1,0])((&<0)(&<[1,1], &<(2..)), &<[1, 2..])
:
J:= n-> Int(1/(1+x^n), x= 0..1, continuous):
S:= thaw(applyop(convert, 1, subs(x^n= freeze(x^n), J(n)), FPS));
                    /  infinity              
                   | 1  -----                
                   |     \               k   
                   |      )        k / n\    
                   |     /     (-1)  \x /  dx
                   |    -----                
                  /     k = 0                
                   0                         

S2:= SwitchOps(S);
                 infinity                     
                  -----  /  /1               \
                   \     | |             k   |
                    )    | |       k / n\    |
                   /     | |   (-1)  \x /  dx|
                  -----  \/                  /
                  k = 0    0                  

S3:= applyop(value, 1, S2);
                        infinity       
                         -----         
                          \          k 
                           )     (-1)  
                          /     -------
                         -----  k n + 1
                         k = 0         

F:= unapply(simplify(value(S3)), n);
      n-> (Psi(1/2/n + 1/2) - Psi(1/2/n))/2/n

#Verification (only valid for n > 0):
evalf(F(9) = J(9));
                  0.9320304240 = 0.9320304242

value(limit(F(n), n= 0, right) = J(0));
                             1   1
                             - = -
                             2   2

@hieudeptrai Enter ?DEplot at a command prompt to get to the help page.

@pazduha Then do

xk = eval(xk, solve({eq||(1..3)}, {xk, xdot, xdot2}));

@Anthrazit The problem with your example procedure is that parse can't create or access local names. Thus, the a, b, and c returned by test (use eval(test()) to see them) are globals. (In this case, that eval is needed to expand a table's name to see its contents (see ?last_name_eval). This only applies to named tables, procedures, and modules, not to rtables.)

Here are two alternatives. I think that the 2nd one is closer to what you're hoping for. There, the a, b, c are indeed local to (and exported from) the Record. But in test1 they are global, so this is risky, and I only show it for the sake of example.

test1:= ()-> table((parse@lhs = rhs)~(["a"=1, "b"=2, "c"=3])):
test2:= ()-> Record("a"=1, "b"=2, "c"=3): 

result:= test1();
             result := TABLE([b = 2, c = 3, a = 1])

result[a];
                               1

result:= test2();
             result := Record(a = 1, b = 2, c = 3)

result:-a;
                               1

@hieudeptrai If you do the search that Tom Leslie suggests, then by extraordinarily good luck the following will happen:

• You'll get only 5 search results. Only one of these is a Maple command: DEtools,DEplot. If you take that link and go to the first example (in the section labeled Examples), the example shown is almost exactly Problem 1 from your assignment; you'd just need to change a few numbers. 

@mmcdara Vote up, but I want to mention some mostly philosophical rather than mathematical issues:

1. You say that your implementation is "very simple". You've implemented an exact test, so I don't see how it could be improved (assuming that the n test subjects are sampled from an essentially infinite population).

2. You mention the possibility of a "continuity correction". Wouldn't that only make sense if one were using a continuous distributiuon (such as Normal(n*p, sqrt(n*p*(1-p)))) to approximate Binomial(n,p)?

3. A lack of sufficient evidence for a hypothesis H shouldn't be claimed to be evidence for its opposite (and I'm not saying that you claimed that it was). Thus, we never "accept" the null hypothesis; rather, we "fail to reject" it or, better yet, say that the evidence is "insufficient". For a scientifically sophisticated audience, this distinction likely makes little difference. But when test results are presented to the general public, one should be careful to avoid language that may cause people to draw unwarranted conclusions from a lack of evidence.

@John2020 

The mathematical concept constant has several definitions as a noun, some of which partially contradict others. For example, compare the Wikipedia articles "Mathematical constant" and "Constant (mathematics)". In Maple (as well as in all other computer languages that I know of that have a concept of constant) a constant is more akin to a mathematical constant---a symbol or name that has a definite and unchanging value. Your a has an unchanging value, but it's indefinite. 

If you attempt to change what Maple means by constant, I think it's very likely that this will cause some future bug, and there's a good chance that this bug will be difficult to track down. There are countless lines of deeply buried Maple code that check for the presence of constants in expressions.

Yes, I realize that your a totally fulfills one of the definitions of constant given in that second Wikipedia article, but that is not the definition that Maple is using.

Another reason to use D for PDE boundary conditions is that it's the most commonly used method.

@syntax I strongly advise you to use the unapply method shown in Preben's Answer rather than anything based on a modication of your original y:= t-> ... method.

There is a variety of different syntaxes in Maple for creating procedures, but semantically they fall into two categories:

1. Evaluation before invocation (this includes unapply): Whatever processing (usually symbolic), simplification, evaluation, etc., that is possible to do before the arguments are given is in fact done, and it's done only once.
2. Evaluation only after invocation (this includes the arrow -> and proc(...)): Those steps are not done until invocation (i.e., when arguments are supplied for the parameters), and they're redone at each invocation.

The empty brackets response that you got from dsolve means that it was unable to give a symbolic (some people say "analytic" instead of "symbolic") solution to your problem, which is no surprise given the order, nonlinearity, and nonpolynomial coefficient. To get a numeric solution, you must give dsolve the numeric option, as shown by Tom Leslie.

@tomleslie The paragraph that the OP quoted is from the help page for NonIsomorphicGraphs in Maple 2021. Perhaps you didn't read the entire page. It's the last paragraph in the Options section.

I agree about the memory/speed tradeoff. That seems like an adequate reason to use outputform= bits. But to me it's not an entirely adequate reason to use selectform= bits, which is what the OP is asking about.

@John2020 I don't think that that Eval will work as a boundary condition for a PDE in Maple. Use functional differential operator D instead:

D[1$3](y)(a,t) = V

The [1$3] indicates the 3rd derivative with respect to the 1st argument position. Note that it's (y)(a,t), not (y(a,t)).

@gkokovidis @tomleslie

The Question is about Maple Calculator. There are no worksheets to upload.

@ecterrab You wrote:

• By the way, the documentation of the Physics:-Vectors package looks clear and complete ... if you feel it doesn't please post some suggestions (thanks) and I will take them a look.

In my Maple 2021.1, there is no help page for ChangeCoordinates, nor is there any mention of this command on the Physics:-Vectors help page. However, the command does exist, and your worksheet executes in my Maple exactly as shown in your Answer.

@Kevin Dragnet To use dchange with my code above requires only 1 change to the code. In the last line, change eval(sys, Tr) to

​​​​​​PDEtools:-dchange(Tr, sys, P)

This does exactly the same thing, and in essentially the same way, as Rouben's Reply two above this one. I've simply hidden my polar coordinates in the list P (for the sake of abstraction). 

@maplefan123 So, is it working for you? not working? somewhere in between? Are you having trouble understanding or implementing something that I wrote? I'm happy to provide more-detailed explanations of anything. Your memory allocation error is perplexing to me, and I want to make sure that's resolved. As I said, the memory allocation for this code is trivial, as is usually the case when an iterator is used correctly^[*1]. Indeed, reducing the memory allocation is a primary reason for the invention of iterators.

[*1] Storing the entire output of an iterator in a container (such as an array) subverts the memory benefit.