@Carl Love 

I too dislike the fact that many newbies "implicitly" define a table just because they want to use variables with what they think is an "inert" suffix - but sometimes I think it is better just to provide "the answer" without going into the details of why it works. Otherwise answers to some "simple" questions could get very lengthy.

Sloppy, I know

Try

restart;
f[1]:=[1,3,2]:
f[2]:=[2,1,3]:
f[3]:=[1,2,3]:
f[4]:=[2,3,1]:
f[5]:=[3,2,1]:
f[6]:=[3,1,2]:
sort([entries(f, 'nolist')]);

@Carl Love 

My default browser is Firefox: I did try the View Image Info, but I don't seem to have the "associated text" option anywhere I can find

Originally I also tried chrome/safari/IE and didn't get anywhere with them either.

I think on this basis, however the OP uploaded the original, ought to be discouraged. Anyhting this hard to read is not a goood idea

@9009134

Assuming you are happy with numerical (rather than analytic) solutions, try something like the attached

equC.mw

@Carl Love Can you actually see/obtain any code from the OP's original post? If so how?

Well, you could try posting the code which is misbehaving.

When posting/editing etc on MaplePrimes you ought to find that there is a biig green up-arrow on the right-hand end of the lower toolbar. The sole function of this icon is so that you can upload code, so that respondents here can analyse/assess/correct your problem

@Boby 

Since m=3 on entry to this loop, and 3 > the end value for the loop index, the loop will never execute. However since nether a[], nor equ[] are used in the subsequent code, maybe this doesn't matter?

The definitions for b[1], b[2], and b[3], ie (for example)

are all recursive with no termination condition and therefore can never be evaluated

OP code is too illogical/irrelevant to even work out what (s)he might be trying to do.

Consider a couple of examples:

The code snippet

will never execute, because the loop start value is greater than the loop final value, and the increment is positive.

Obviously one could make this execute by specifiying a negative decrement as in

However this would only assign the same values to the same variables, three times - which would also be completely pointless. Nothing within the loop depends on the loop index, so why assign the same value to (eg) a[1] three times?? This is plain stupid - why not just write

As a second example of completely superfluous, illogical, code consider the loop

Note that the loop always operates exactly m times, So starting with k:=m+1, and performing k:=k-1 exactly m times will result in k:=1. Similar considerations apply to n1: if m:=0, then the loop never executes and n1:=1, if m:=1, then n-1:=-1 and so on - in other words n1:=(-1)^m, so that above code sequence can be replaced by

k:=1;n1:=(-1)^m;

and as a side effect

r1:=m, which since m is known seems a bit superfluous

Since there is so much of this kind of totally illogical, superfluous, crap in your worksheet, I cannot actually work out what you are trying to achieve so I can't help much

@acer 

There is no variable epsilon in either of the OP's worksheets - am I missing something?

@tobbie247 

In your original post you state "it seems to evaluate forever."

I have just checked both of your supplied worksheets. On my machine (reasonably quick but nowhere near leading edge) the worksheet DTM_result.mw executes in 0.4secs and the worksheet numerical_result.mw executes in 0.1 secs.

Which of these do you consider taking "forever" to evaluate"?

If execution time is not your problem, what is it? exactly

Consider your problem with the angular variable equal to Pi/2:

tan(t)/cos(t) then has an infinite numerator and a zero denominator - that's a seriously big (ie infinite^2) number. You really don't want to try plotting that. Try playing with

par:=0.5:
plots:-polarplot(tan(t)/cos(t), t=-par*(Pi/2)..par*(Pi/2));

where the value of 'par' can be any number < 1

Running Maple 18.02, BUILD ID 991181 on 64-bit win7 with all updates, I get the error which Preben originally reported - in other words, for me,  dsolve/numeric/compile=true does not work!

So yours_works/mine_doesnt - what could be different in our installations????

Venkat,

I'm not trying to be difficult here, because (like Preben) I would like to get a "fully" functional installation, but I am going to cut apart your response and highlight my own experience issues. Your statements are italicised, my responses follow

My understanding is that Maple's Compiler:-compile and dsolve numeric use different compilers.

No problem with Maple using two different compilers - so long as both of them work!. My (Preben's?) issue is that Compiler:-compile works and dsolve/numeric/compile=true doesn't!! So, obvious question - how do we make both of them work????
***********************************************************************************

It is possible to download and install mingw and use that for dsolve/numeric by linking to it from Maple

Well OK if this is the only solution? But I already have one functional c-compiler working with Maple (the one used by Compiler:-compile): I have another functional c-compiler as part of my "pretty vanilla" netbeans/cygwin/gcc installation - which works just fine for my (pretty limited) standalone c/c++ requirements.

I reaslly would prefer to get the dsolve/numeric/complie=true option working with one the two c-compilers I already have.

Do I really (really) need a third c-compiler in order to make to make the compile=true option work for dsolve/numeric????
***********************************************************************************

Also, this might have to do with windows 10 moving away from win32 to sandbox appraoches. Hope that is not the case and that it is an easy fix.

Don't think that this comment is particularly relevant. Preben has established that dsolve/compile=true doesn't work on 64-bit win8/win10, and I can confirm that it doesn't work on 64-bit win7. The rather obvious conclusion is that the dsolve/compile=true option does not work on any 64-bit windows OS. Anyone who can make this option work on any 64-bit windows OS - please tell us how!!
**********************************************************************************

My 64bit maple compiles in Maple18/windows 7 configuration. However there is no gain in precision (You can use only Digits:=15. So, you don't lose anything staying with Maple 32 bit installations for compile=true approaches)

This comment is a bit ambiguous, and I am not sure I understand it. For example, I have a 64-bit Maple 18 running on a 64-bit windows7 system. the Compiler:-compile command works for all help page samples, but the dsolve/numeric option complie = true throws the error reported by Preben. So when you say

My 64bit maple compiles in Maple18/windows 7 configuration.

Are you running 64-bit win7? Because if your"64bit maple compiles in Maple18/(64-bit) windows 7 configuration." then you have achieved something which no-one else has" - ie dsolve/numeric/compile=true works on a 64-bit windows installation - please tell us how!

FYI

1. I'm running Maple 2015.1 on 64-bit win7 (haven't got around to updating the OS yet!), and see the same issue as Preben, ie
2. Samples on the Compiler:-Compile help page all seem to work
3. dsolve/numeric with compile=true gives the error message which Preben has reported
4. Identical behaviour when running Maple18.02 on the same machine

@Markiyan Hirnyk 

Whilst Markiyan is correctas far as it goes, the information is incomplete.

Example: so far as I am aware no-one knows how to change the font size in the standard interface, interactive debugger, output pane - although I'm always willing to be proved wrong!!