Let me state first of all that I think you have a legitimate complaint, which is (I think) is worth informing Maple Technical support.

Having said that, in Maple's defence, it is interesting to compute the probability distribution function (PDF)

P:=PDF(cos(RandomVariable(Normal(0,1))),x),

which looks plausible because it returns a piecewise function defined as zero when  x>=1. On the other hand it is interesting to look at the limit of this piecewise function as x approaches 1 from the left, which can be done with

limit(op(4,P),x=1,left);

which returns infinity - yes, for this distribution, the pdf tends to infinity as x->1 from the left. Have to admit that surprised me!!!

This behaviour can be confirmed by plotting the PDF around 1 using something like

plot(P, x=0.99999..1.00001);

which shows that there is a "serious issue"/discontinuity in the PDF at x=1

The CDF is just the integral of the PDF, so one can compute/verify this as either

C:=CDF(cos(RandomVariable(Normal(0,1))),x)

or

C:=int(P,x)

which both give the answer yoiu have already obtained (not surprising really since the CDF is just the integral of the PDF and I suspect that this is the way it is computed in Maple).

What is surprising (to me at least) is that both give erf(Pi/sqrt(2)) for x>=1, ie . Given the infinite discontinuity at x=1, I'm not particularly surprised that Maple has problems around x=1, but what does surprise me is that erf(Pi/sqrt(2)) isn't actually that close to the expected value of 1 - it evaluates to 0.9983196837 - close but no coconut. For the purposes of comparison

fsolve(erf(x)=1,x) returns 11.08829107, which is a long way from Pi/sqrt(2)

Summary: although your distribution looks innocuous, it does have a seriously ugly discontinuity, but I think Maple should do a better, so I recommend you reprot this to the Maple techies

@In-Jee Jeong 

The command you claim to be using, ie - copied from your original post

Sol := dsolve({seq(ode[j], j = 0 .. 21), seq(v[j](0) = 0, j = 1 .. 21), v[0](0) = 1}, [seq(v[j](t), j = 0 .. 21)]);

will look for analytic solutions - it will not solve numerically!!!!! So when you say, "Unfortunately I am solving the system numerically" NO YOU ARE NOT!!! It would be so much easier to help you if you uploaded the code you are trying to run, rather than making inconsistent and obviously incorrect statements. (Uploading code is done using the big green up-arrow, right hand end of the second row of toolbar icons)

If you are indeed using a different command to produce numeric solutions, then you should be aware that all a call to

dsolve(loads of equations, variables and options, numeric)

actually does is to return a set of procedures which allow subsequent commands to generate specific numeric solutions depending on exactly what you want to do next. At this stage no "solutions" have been computed, jus procedures which will compute the solutions you subsequently specify

Well if you upload the worksheet including the required procedure, someone might!
Upload code using the big green arrow, right hand end of the second row of icons in the toolbar

@Carl Love 

Whilst I generally agree with above statement, I was trying to make the point that an n*n matrix would always have n eigenvalues - they might not be distinct, there may be complex conjugate pairs, whatever, but there would always be n eigenvalues. However an apparently "similar" matrix defined over a finite field might *seem* to have no eigenvalues.

Apparently one can apply something called "field extensions" specifically to "solve" this problem. In other words no eigenvalues exist, but if one "extends" the finite field, then eigenvalues can be persuaded occur. This is getting beyond my capability in maths. But is it "cheating"? - wouldn't it be simpler/better to say that for some matrices over finite fields, then no eigenvalues exist???? I don't know

Concrete example: run  the matrix M= [[2, 8],[3,8]] modulo 9 in your code: no eigenvalues are returned. Why?

@zia9206314 

All I did was execute the file integral.mw which you posted originally. It defines/calculates eight integrals: I got the answers at the evalf(%) stage as

0.5160944460

-0.1221257810

0.05621481789

-0.03313111519

0.02218299918

-0.01605629618

0.01224881342

-0.009704616638

See the attached: NB don't *execute* the worksheet below because my answers might disappear - just read the answers

ints2.mw

Like I said earlier, I did this in Maple 2015 running on 64-bit Win7. If your original worksheet does not provide these answers then it would seem to be a problem either with Maple version (I can't run Maple 17 because I don't have it) or operating system.

What answers do you actualy get when you execute your own worksheet??!!!!

I know you are running Maple 17, but what operating system?

@Carl Love 

Carl,

Even worse than his previous post 

@Preben Alsholm 

Preben/Rouben,

I got this singularity answer (funny how I remember the exact number) when I tried to fix the OPs previous post (about 4/5 threads earlier than this one). I fixed a lot of stuff in his original which looked like simple misunderstandings eg

bm=1.2*(e)^(-4) ,cm= 0.5*(e)^(-5) (there are other examples!!)

which in the current code seem to have become bm = 1.2*exp(-4), cm = .5*exp(-5)

I went through the whole of the OPs previous post *guessing* what was intended at each stage, eg for the above examples, bm=1.2e-4 ,cm= 0.5e-5. (There were quite a few others)

I ended up with a worksheet which seemed to produce plausible output curves. I uploaded this worksheet so that OP could check my *guesses*.

OP has chosen to ignore this and start a new thread with (more or less) the same bum code. I have no idea why.

Or if you want all of your functions (u, theta, phi) on the same graph in different colors use

with(plots):
soln := pdsolve(PDE, IBCs, numeric);
p1:=soln:-plot3d(u(y,t), t=0..1, y=0..1, color=red):
p2:=soln:-plot3d(theta(y,t), t=0..1, y=0..1, color=blue):
p3:=soln:-plot3d(phi(y,t), t=0..1, y=0..1, color=green):
display([p1,p2,p3]);

1. Don't post images of your code. It means that anyone who wants to work on it will have to retype your code, and that isn't going to happen: too time-consuming, too error-prone
2. To upload code, use the big green up-arrow, right-hand end of the second row of toolbar icons.
3. Clarify your problem: for example when you say you took " the derivative of this function wrt p", I assume that you mean you executed the command diff(delt, p)?? - uploading your code would make this so much clearer!!
4. I am slightly worried by the fact that in some of your expressions involving P_B(p-w) there appears to be a space between P_B and (p-w) and sometimes there is not - which suggest that you are using 2-D input and can't tell the difference between the product P_B*(p-w), and the function P_B with argument (p-w), ie P_B(p-w). If you had uploaded your code in an editable/readable fashion then I could probably give you a definitive answer immediately

@Markiyan Hirnyk 

The LinearAlgebra[Modular] subpackage not only allows the definition of matrices over finite fields, but rpovides several command for their manipulation. In the case of eigenvalues, probably the most interesting is LinearAlgebra[Modular][IntegerCharacteristicPolynomial] which should return the characteristic polynomial. The roots of this polynomial should provide the eigenvalues. However their is no known method for guaranteeing the computation of roots for polynomials of order > 4, so I see two possibilities

If your matrices are generally 4*4 or less then some combination of LinearAlgebra[Modular][IntegerCharacteristicPolynomial] and "msolve" ought to determine appropriate roots (ie eigenvalues). However above order 4 polynomials, then, generally speaking, numeric methods are required for determining eigenvalues. Whether or not standard numerical methods can be modified to operate "modulo m", I'm not sure. Sounds possible but difficult.

In particular I suspect that having drastically restricted the possible domain for eigenvalues, then logically one would expect that there would be fewer matrices for which eigenvalues could be determined.

I get the feeling that this is one of those problems where you have to experiment to find out - althoug like I siad Maple seems to have most of the bit you would need

So many syntax errors again!

I fixed all the syntax errors for the worksheet in your previous post and uploaded a corrected version which you should run

You may be determined to repeat the same syntax errors, but I (for one) won't be fixing them again.

If your system of equations is reasonably strongly coupled, eg your DE for f[0,0](x) depends on f[77,9] which in turn depends on f[123,6] and so on then you cannot "solve" for one function without simultaneously solving for all the others - which you don't want to do.

Your question is analogous to asking for a solution of say 10 simultaneous (non-differential) equations in 10 unknowns where you would like to compute the solutions for a couple of the unknowns without computing the solutions for all the others - not possible in general

If you system is weakly-coupled, for example the DE for f[n,m](x), depends only on say f[n-1,m-1](x), and f[n,m](x), then you may be able to subdivide your problem into sets of equations where each set is independent of the others. Then you can solve each set separately.

I would think that it is pretty unlikely that your equations would meet this (very restrictive) requirement

OP has a system of ODES which *apparently* can be solved analytically - there is no "numeric" option in the dsolve command

Assuming that this dsolve command does work then you should have a list/set of solutions, any combination of which can be plotted using simple plot commands - no need for odeplot.

So system will only be solved once, at which point you just plot solutions or combinations of solutions using plot()

Read the DETools[phaseportrait] help pages

@h8red 

When you said that "i would like the to get the answer -exp(-n(cos(phi)+sin(phi))) from the 'simplify' command", I assumed that this was the answer required from the second simplify command, in which case my reply stands.

It now seems that this is the answer which you want to get from the first simplify command - in other words you want the big nasty complicated factor in n to evaluate to -1. Well it might be posible to do this, but some manipulation of the expression might be necessary. Try uploading code which results in this expression, because my life is too short to retype it.