@ishan_ae

I changed to assume n is a positive integer, then the sin(n*Pi) and cos(n*Pi) can be simplified. assume(N>0) has no effect since the N within the fourier_f is not the same as the one outside.

The delayed evaluation quotes around 'add' are because at the time the fourier_f definition is evaluated, the value of N is not known. This prevents add from generating an error because N does not yet have a value. In the animated one, I have needed to do this twice.

display is in the plots package so needs to be plots:-display (or use with(plots): at the start of the worksheet).

If you use sum instead of add, it tries to work out the general formula every time sum in encountered, which slows it down significantly.

Here it is working.

Download fourier_analysis.mw

Not clear if this is OK - you can remove input from the worksheet using view->show/hide contents and then export to .pdf (or print to .pdf with a .pdf printer driver)

@sursumCorda Finally got a version with topological sort to work, added to the above - about twice as fast.

[Edit - I removed a redundant line of code and now can't reproduce the faster timing - it's about the same.]

Have never used these and they might not be what you want, but there is a Grading package, and Maple TA. The help page ?MapleTAIntegration has a number of useful links.

This works for me so presumably something about your installation is different. I suggest you contact technical support

compile_ex.mw

@sredh01 Your main problem is the absence of the RandomMatrix(n,n,generator=-5..5): Here's a version that generates a given number of matrices.

GivenDet2.mw

@ijuptilk I interpreted your question "Hi, please can someone help on how non-dimensionalize PDEs. I have tried the following, but is not working" as meaning "I know how to non-dimensionalize, and was in the process of non-dimensionalizing when Maple gave an error, so could someone please solve the Maple error". So I made the various substutions exactly as you had them. You presumably actually know the dimensions of various quantities, and I wouldn't normally attempt a non-dimensionalization without that information.

More generous MaplePrimer @sand15 = @mmcdara interpreted your question as requesting a complete solution to non-dimensionalize your equation. But they are slowed down in this by having to deduce things, like the f[1] and f[2] interpretation, which you have only now provided, and now we see that K[1] and K[3] appear more often than they did in the original equation. So are you OK with a solution without f[1] and f[2]? Your response is not very clear about this. You also have not commented on @mmcdara's analysis. Perhaps you now know how to proceed with the tools at hand and that is the end. But if you want more, some more information about what you know and what you want would seem appropriate. 

@ijuptilk I'm assuming the problem is in the last step. Try adding params=[K[1],mu]. I'll update the other one. Or perhaps Maple is hinting that you should take @sand15's advice :-)

@mmcdara Nice analysis. For the case where you postmultiplied the Gram Schmidt matrix by DiagonalMatrix( [1$(N-1), T*sign(d)]) you have scaled the last column by magnitude T, so they are random but with a different range from the other columns. Your next example solves that problem.

I was trying to work an integer case based on GS.DiagonalMatrix( [1$(N-1), T]).GS^+ (which solves the above problem, I think), but if T=1, then you get the identity matrix, which suddenly is not very random, even though T<>1 looks random. This made me wonder if the entries of GS itself are too correlated to be random, but that is beyond my limited statistics expertise.

@lcz Tarjan's algorithm seems to be standard, and was for directed graphs, (but works also for undirected if allowance is made for the double counting). So, yes it is strange not to have the capability for both.

It was the fastest of the algorithms I played with, but perhaps with dense graphs other algorithms might be better. Tarjans's could probably be converted to a compiled version in Maple, if the stack was implemented "by hand" using arrays. I was originally thinking algorithms based on cycle basis was the way to go, but the literature doesn't seem to point to that.

I also have another version that uses Zeon algebra, but just counts and doesn't produce the cycles themselves, so I added it to the other thread:

How-To-Determine-The-Number-Of-Cycles-Of--Graph

Infolevel gives information that is not that enlightening. 

solve.mw

I can't decide whether this is a bug, or whether we are expected to be cautious when mathematical functions like ln are involved.

@lcz ?GraphTheory,Details for the documentation. op(4,G) is the Array that is very similar to what Neighbor returns, though Neighbors uses the names of the Vertices rather than the numbers.

In fact, since almost all (all?) other GraphTheory commands return vertices as names, it seems like an oversight (bug?) that IsChordal returns the numbers of the vertices. But it is so poorly documented it is hard to tell what was intended.

@Carl Love I wasn't suggesting the stop button as a solution to those longer term issues. The OP's description suggested that they lost worksheets when this hangs, which suggests that their system is not responding to the stop button, or the exit application button (which often gives an oppportunity to save even if Maple has ceased responding). If that is the case, then my comment might suggest that there is some system difference that technical support might solve.

@MaPal93 The quintic has all coefficients positive, except for the constant term, which is negative. So if you removed the constant term and plotted it, it goes through the origin and then is monotonically increasing as x increases. Adding the (negative) constant term brings the curve down, and will mean there is exactly one positive root. (Sturm sequences tell something about location of real roots in the more general case; Maple has them only for constant coefficients, but you could apply them for the general case, though I'm not sure this will do much better than solve( , parametric) or the other solvers with inequalities.)

I am trying to formulate your three equations as much as possible in matrix form. Of course you probably got them from some matrices in the first place so I am probably just reverse engineering here. I don't know much about statistics but am reasonably fluent with matrices. I see the matrix origin of the betas. Then in your equations:

the matrix origins, if any, are much harder to see. Would you mind answering some questions that might help me with this?

1. In these equations you introduce new variables Cov_S12, Var_S1, Var_S2, Var_nu1, Var_nu2, Cov_nu12 - is there any relationship between these and the earlier variables?

2. You also have the variables Var_u1, Var_u2, Var_u3 that were used previously. In the earlier equations that you solved, these (and all the other variances and covariances) got multiplied by gamma. Should these also be multiplied by gamma here? Or perhaps gamma multiplied the other new variables as well and then cancelled in these equations?

3. Is theta__12 = theta__21?

4. Since beta__12 is not the same as beta__21, 2*beta__11*beta__12*Cov_S12 is not the same as beta__11*(beta__12+beta__21)*Cov_S12. The latter form seems more natural for a matrix formulation. Is it correct as written or is there perhaps a hidden assumption here?

Here are my manipulations so far:  Matrix4.mw 

If you think this is a profitable approach, I'd be happy to elaborate on this.