@Carl Love 

I just obtain

Sol(1);
Error, (in Sol) cannot evaluate the solution past the initial point, problem may be complex, initially singular or improperly set up

plots[odeplot](Sol);
Warning, cannot evaluate the solution past the initial point, problem may be complex, initially singular or improperly set up
Warning, cannot evaluate the solution past the initial point, problem may be complex, initially singular or improperly set up

But the real problem is that using minstep you force dsolve to output something even if the solution does not exist.

@Carl Love 

This approach has a serious flaw. For such an R the ODE has no solution (mathematically). Actually the code will not work unless R(t) is multiplied by a smaller number.
I think that the correct approach is to take R(t) a "continuous random" function e.g.

r:=seq( rand(0.. 0.01)(), i=1..10):

R:=unapply( add(r[i]*cos(10*i*t),i=1..10),t  ):

eq:=diff(a(t),t,t) + a(t) = 3.*(1+R(t))*cos(5.*t):

Sol:= dsolve({eq, a(0)=0, D(a)(0)=1}, a(t), numeric);

plots[odeplot](Sol);

@Carl Love 

The problem is (see the previous answer) that the solution for d is actually d=0, and OP wants d<>0, impossible.

@Josolumoh 

It is definitely not a discrete pdf for an arbitrary (r,b,d).

If the discrete values are {0,1,2,...} then e.g. for [r=3, b=2, d=0.01411053479], F is a pdf.
So, you must choose first the right parameters (and maybe also the discrete values).

@want to be a permanent vegan 

Just add after kitonum's code:

E:=0.5*(y(t)^2+w^2*x(t)^2):
J:=E/w:
plot([E,J], t=0..10, color=[red,blue], thickness=2, legend=['E(t)','I(t)']);

@max125

In 2D input mode you are not forced to use the strict maple syntax. The interface will adjust your input to conform to this syntax before sending it to the maple engine. E.g. a multiplication operator * could be added.

@max125 

You see exactly what you have typed and your input is not parsed.

@max125 

No, you are not, according to the provided print screen.

Use the menu

Tools > Options > Display

@Carl Love 

Perm1to2_E:= (L1::list, L2::list)-> subs(`=`~(L1,[seq(1..nops(L1))]), L2):

n:=100000;
f:='randpoly([x, y])':
L1:= ['f' $ n]:
L2:= combinat:-randperm(L1):

                             100000

Perm1to2_D:= (L1::list, L2::list)->
     sort(L1, output= permutation)[sort(sort(L2, output= permutation), output= permutation)]:
Perm1to2_E:= (L1::list, L2::list)-> subs(`=`~(L1,[seq(1..nops(L1))]), L2):

PD:= CodeTools:-Usage(Perm1to2_D(L1,L2)):
evalb(L1[PD] = L2);
PE:= CodeTools:-Usage(Perm1to2_E(L1,L2)):
evalb(L1[PE] = L2);

memory used=10.09MiB, alloc change=8.86MiB, cpu time=187.00ms, real time=156.00ms, gc time=0ns
                              true

memory used=14.06MiB, alloc change=8.77MiB, cpu time=124.00ms, real time=125.00ms, gc time=46.80ms
                              true

Edit: An even faster one:

Perm1to2_E_bis:= proc(L1::list, L2::list)
local T;
T:=convert(L2,Array);
subs[inplace](`=`~(L1,[seq(1..nops(L1))]), T):
convert(T,list)
end;

@Carl Love 

I was intrigued by your version of cartprod.

Could you please answer the following questions.

1. The order in the resulting list is reversed lexicographic, unlike cartprod where the order is lexicographic.
What changes are needed to have the same order?

2. I have tested the speed of both versions for a list L given by

m:=7;n:=10; # then n=12
L:=[seq( [seq(10*i+j,j=1..n)], i=1..m)];
p:=n^m;

I have used only time[real]():

T:=combinat[cartprod](L);
t:=time[real]():
nops( [ seq(T[nextvalue](),i=1..p) ] );
time[real]()-t;

I was surprised to see that CartProd was only about twice faster than cartprod for such large lists.
How do you explain this?
Have you an ideea about complexity in both cases?

Best regards,
V.

@Markiyan Hirnyk 

Just to prevent nonsense inputs:

rad := proc(u::polynom) `*`(op(map( z->op(1,z),factors(u)[2]))) end:

@Markiyan Hirnyk 

The ring of the polynomials, of course, K[x,y,...], K an extension of Q.

@Markiyan Hirnyk 

1. The results are the same, modulo the units of the ring.
One may apply primpart to all the terms, but it is not necessary.

2. You are right. But over the reals, factors works better.
And if we consider e.g. polynomials over a noncommutative field, then both methods fail. :-)

@Markiyan Hirnyk 

I lnow that it may fail; actually it could be fixed.

The real point was that factor could work where Radical fails.

@Markiyan Hirnyk 

Radical also fails for such polynomials (with irrational coeffs).

factor may work. E.g.

g:=expand((x*sqrt(2)+y*sqrt(3)+z*sqrt(6)+x*y*sqrt(6)+x)^6):
r:=factor(g):
if op(0,r)=`*` and type(op(1,r),realcons) then r:=op(2,r) fi:
if op(0,r)=`^` then op(1,r) else FAIL fi;