I think that this is the easiest way (and it's also very efficient), but it only works since Maple 2018 and only using 1D input (plaintext input). Let's say that you have a loop that's producing output with each entry on its own line, such as

for k to 9 do
    ithprime(k)
od;

Then change that to

L:= [
    for k to 9 do
        ithprime(k)
    od #no semicolon here!
];

That works for any do loop; it needn't be a for-do loop.

The line-breaks and other spacing in my code are just for emphasis. You could just as well use

L:= [for k to 9 do ithprime(k) od];

If the original loop delivers its output via a print command, then you'll need to remove the print.

Only the values produced on the last "line" of the loop (i.e., right before the od) will be included in the list.

The analytic solution for x(t) in the ODE system in your original Question is the constant function x(t)=1. (This is obvious, but let me know if you need further explanation of why that is.) In your followup, you plotted the analytic solution functions x(t) and y(t) for a similar---but not identical---ODE system. The crucial difference is that x(t) is not constant there because you changed its initial conditions.

The output of odeplot(dsolve(..., numeric)) is not a parametric plot of y(t) vs. x(t); it is a plot of x(t) vs. t. In that plot, there is some miniscule variation of x(t) due to the numeric approximation process used by dsolve. This variation is entirely in the 16th decimal place and beyond, which makes it many orders of magnitude smaller than the stated error limits for numeric dsolve. Since x(t) is otherwise constant, this variation in the only variation in the vertical coordinate, so it alone determines the scaling of the vertical axis. It is unreliable and inefficient to try to control this with numpoints (won't work) or Digits (might or might not work; inefficient). If for some reason you actually want a plot whose only content is a constant function, use the view option to set the scaling (for example, view= [0..10, 0.9..1.1]).

Here's how to tell odeplot the functions that you want to plot:

restart;
g:= 9.81;
sol:= dsolve(
    {
        diff(x(t), t, t) = 0, diff(y(t), t, t) = -g + y(t)^2, 
        x(0) = 1, y(0) = 0, D(x)(0) = 0, D(y)(0) = 0
    }, 
    numeric
):
#Plot x(t) and y(t) vs. t on the same axes:
plots:-odeplot(sol, [[t,x(t)], [t,y(t)]], t= 0..10); 

It doesn't make sense to do a parametric plot in this particular case, one coordinate being constant. But otherwise the function specification could be [x(t), y(t)].

If you make the function specifcation [t, x(t) - 1], you'll see that all the variation in x(t) is in the 16th decimal place and beyond.

That should be 

f:= x-> piecewise(...)

just like you had in your earlier Questions. (I wonder why you didn't notice that?)

That's quite a weird error message though! Don't bother trying to understand it at this point; I think that it may be intended primarily for developers.

The command lprint(eval(r)) could be used as an aid for checking whether you've entered r as intended. All implicit multiplications will be shown explictly as *. There are two spots where I think that you intended multiplication, but it doesn't appear, which I've highlighted below with ^^.

lprint(eval(r));
(phi, B, theta) -> sqrt(-B^2+(a^2+B^2)*cos(theta)^2*f)(sqrt((-B^2+(a^2+B^2)*cos
                                                     ^^
(theta)^2)/(a^2+B^2)/cos(theta)^2)(phi-sqrt(a^2+B^2)*cos(theta)/sqrt(-B^2+(a^2+
                                 ^^
B^2)*cos(theta)^2)*arcsec(a/sqrt(-B^2+(a^2+B^2)*cos(theta)^2))))

2D Input usually requires a space between operands in order for it to be interpreted as multiplication. This is especially important when the right operand is in parentheses because the syntax checker usually won't catch the error in that case (because such expressions have a legitimate interpretation other than multiplication).

Also, the lprint shows that f is the last operand "under" the first square root. Did you intend for f to be outside that square root instead?

If I make these changes, I get this plot:

Is the returned p a local variable, perhaps local to the procedure that returned it? That would be the most likely explanation. 

Otherwise, we need to see the code that returns p.

The spectral radius is also the maximal singular value^[*1]. Regardless of whether you use command Eigenvalues or SingularValues from LinearAlgebra, numeric results can be quickly obtained by converting the Matrix to datatype= hfloat.

restart:
SpectralRadius:= proc(G::Graph)
uses LA= LinearAlgebra, GT= GraphTheory;
    (max @ LA:-SingularValues)(
        rtable(GT:-AdjacencyMatrix(G), 'datatype'= 'hfloat')
    )
end proc
:
GT:= GraphTheory: SG:= GT:-SpecialGraphs:
M22:= SG:-M22Graph(); #This graph is 16-regular.
      Graph 1: an undirected unweighted graph with 77 vertices 
      and 616 edge(s)

CodeTools:-Usage(SpectralRadius(M22));
memory used=241.62KiB, alloc change=0 bytes, 
cpu time=16.00ms, real time=6.00ms, gc time=0ns

                        16.0000000000000

[*1] The singular values of a real or complex matrix A (not necessarily square) are the square roots of the eigenvalues of A . HermitianTranspose(A). These are necessarily nonnegative reals. In the square floating-point case, these can be computed more efficiently and more stably than the eigenvalues of A itself.

The _Y could be replaced by any otherwise unused variable. It's what logicians and computer scientists call a bound variable, and here it's bound to the DESol expression. Mathematicians sometimes call it a dummy variable, but I disdain that term. So, the important thing is what DESol means rather than what _Y(x) means.

So, Maple can't solve your ODE, but it can simplify it a tiny bit. It's saying, essentially, "Here's another, perhaps simpler, ODE (the 1st argument of the DESol equated to 0) whose solution is the same as that of your original ODE." Now, you may think that this new ODE is such a trivial change from your original that it's hardly worth stating, and if all DESols returned by dsolve were that trivial, then I'd agree. But sometimes they're not so trivial.

You could try exporting the worksheet as PDF and then copy-and-paste from the PDF. From the worksheet's File menu, select Export As, then select PDF from the "Files of type" pull-down.

A variation of Tom's Answer:

select(j-> j[[4,7]] = [[C,Z], [B,Y]], Perms)

One way:

solve(2*a +~ (b+2)*~[0,1] =~ [1,1]);

Another (this one doesn't use elementwise operations):

x:= t-> 2*a+b*t+2*t:  solve({x(0)=1, x(1)=1});

Another:

solve((t-> 2*a+b*t+2*t)~([0,1]) =~ [1,1]);

Here's an exercise for you. By using the help pages and asking here for pointers to the correct help pages, figure out what this code does and how. It's very much related to your questions about odds, evens, and squares. (My code is dense, but nothing has been intentionally obfuscated.)

EvenSqrSeries:= proc(N::And(posint, odd))
local 
    n:= N, e, 
    sq:= proc(n) 
    local r:= isqrt(n); 
        if r^2 >= n then r-- fi; 
        `if`(r::odd, r-1, r)
    end proc
;
    add([while (n-= (e:= sq(n))^2) > 4 do e od]%^~2) + n
end proc
:

n:= 2*rand(10^99..10^100-1)() + 1;
   [output omitted]
EvenSqrSeries(n);
   [output omitted]
value(%);
   [output omitted]

This code needs to be run in 1D input (plaintext input).

Sort the DataFrame by the date field before you extract the TimeSeries. Let's say the DataFrame is named DF, and the date field is named mydate. Then do, quite simply,

newDF:= sort(DF, mydate);

Then do whatever you did before to extract the TimeSeries, but do it to newDF rather than to DF.

See help page ?DataFrame,sort.

@nm You wrote:

• The program can't call dsolve twice each time in order to make sure it gets the smaller infolevel output. That will be too inefficient.

That's not true, due to the efficiency provided by the remember tables. Using the ode from your worksheet posted above, I did the following:

• I ran the dsolve without setting infolevel, which took 17.64 seconds;
• then I set infolevel[dsolve]:= 2 and reran the dsolve to get the shorter userinfo output, which took 0.141 seconds.

Thus, the 2nd running was 125 times faster than the 1st.

Then I timed the longer userinfo output: I did restart, set infolevel[dsolve]:= 2, and ran the dsolve again. This took 19.5 seconds, which is 10% more than the sum of the previous two runs. So, in a sense you'd actually be saving time by running it twice.

I'm sorry that I didn't step into this discussion earlier. The code below does what that Matlab code was intended to do (implement a discrete simulation of a 1D Wiener process), and it gives you a function (e.g., B) that can be evaluated at any value in a specified interval in the usual way, such as B(1.2).

This requires Maple 2018 or later. If you have an earlier version of Maple, let me know, and I can easily adjust this.

restart:
Wiener1D:= proc(
    T::range(realcons), N::And(posint, Not(1)), W0::realcons:= 0
)
description "Discrete simulation of 1D Wiener process";
uses AT= ArrayTools, In= Interpolation, St= Statistics;
local 
    a:= lhs(T), b:= rhs(T), dt:= evalf((b-a)/(N-1)),
    t:= rtable(1..N, i-> a+(i-1)*dt, datatype= hfloat),
    W:= evalf(W0) +~ AT:-ScanAlongDimension(
        `+`, St:-Sample(Normal(0, sqrt(dt)), N), 'inplace', evalhf
    )
;
    W[1]:= W0;
    In:-LinearInterpolation(t, W)
end proc
:

Example usage:

randomize():
B:= Wiener1D(0..2, 10^5):
B(1.2);
                       -0.488707422425162

plot(B, 0..2, numpoints= 1000);

This and other stochastic integration simulations can also be done by the Finance package, as I mentioned before.

You might as well use the command specifically made for extracting a sublist based on a boolean condition of the elements: select:

points2:= select(p-> andmap(x-> abs(x)<5, p), points);

A slightly slicker variation is

points2:= select[2](andmap, x-> abs(x)<5, points);

These methods require no indexing and no counting, neither of the overall list nor of its list/point elements; they'll work, unchanged, for any list of lists of explicit real numbers.