@Mariusz Iwaniuk You need to change method= classical to method= classical[rk4]. Without this, it's using Euler's method.

@taro Here's a worksheet showing a way to do what you asked.

Download rtable_order.mw

In both cases that it's used, ArrayTools:-Alias produces an inplace copy of a 2x2x2 parent Array as an 8-element row Vector. (ArrayTools:-Alias can only be used to make inplace copies.) The rtable(..., order= ...) command makes a true copy of the parent.

It may be possible to make an inplace copy in the other order by using an indexing function. I've never done that, and I have some doubts that there'd ever be an efficiency benefit from doing that. From reading the Maple help, you may think that there are some commands that can change the order inplace. No, these commands just change the order attribute without changing the actual order. I mean that they simply change---by a trivial relabeling---the value of the order attribute.

Please make sure that you understand the difference between inplace copy and (true) copy. See ?copy, and note that the examples that are shown there for tables apply to rtables also.

Please read these help pages: ?worksheet,managing,exporttolatex and ?latex,viewing. If you then still need help, please upload the relevant files. Use the green up-arrow on the toolbar of the MaplePrimes editor to upload:

1. the worksheet (either as .mw or .mws);
2. the LaTeX (you'll need to rename .tex as .txt in order for MaplePrimes to allow it);
3. the PDF (as .pdf).

And please describe exactly what you did to produce file 3 from file 2.

@taro Maple is designed so that the effect of order isn't usually apparent to the casual user. You may only notice it if you use ArrayTools:-Alias, which'll give very wrong results if you don't respect the order, or convert(..., list), which'll just give different, but not wrong, results.

As you may be able to guess from the names of the option's values, C_order and Fortran_order, this issue is much older than Maple itself.

@Kertab24 Transforming multiple definite integrals to other coordinate systems, such as polar, is not something that's handled well, if at all, by computer algebra systems, such as Maple. Transforming the integrand (the sqrt(x^2+y^2) in your case) is relatively easy, and they can generally handle that. The hard part is transforming the limits of integration, which come from the boundaries of the region of integration (the rectangle in your case). As I think you realize, this requires some visualization skill, or, as you said, "imagination".

So that I don't go too far with explanations that you may not understand, please give me some background on your education:

1. Do you have any familiarity with (or recollection of) polar coordinates?
2. How long has it been since you've formally taken a graded course in calculus? I don't mean just reading a refresher.
3. What about multi-variable calculus, which is where double integrals are covered? For science/engineering/math majors, this would usually be the third-semester course in calculus.
4. Do you still have the textbook for that course? If so, give me the publication details.

Feel free to send me a private email by selecting "Contact author" from the "More..." pull-down menu at the botton right of this message. I offer private online calculus tutoring.

The error message is unrelated to the commands, and I'd guess that it has something to do with the GUI display.

Try putting each command in a separate execution group. A restart should always go in a separate execution group. It usually causes no problems when it's not, but it does sometimes cause problems, and they can be weird.

If that doesn't work, try typing control-M to change the input mode to Maple Input. Then type control-J a few times. This creates spaces for Maple Input / plaintext execution groups. Then enter the commands again. They should appear in an upright monospaced font.

@taro The meaning of the :: operator is not always related to properties or types. It's true that the vast majority of its uses are to check a property or type or to assign a property. But it's essentially a neutral operator whose meaning is determined by the procedure to which it's passed. The operators ::, =, .., <, <=, in, subset, and <> are all like that: They execute no code automatically, do no argument checking, and their meaning is determined by whatever procedure processes the expression containing them. (In some cases they can me made to automatically invoke some code when their operands are specific types.)

If A is a module, and B is a procedure in A, either a local or an export, then showstat(A::B) shows the code of B. It turns out that `convert/list` is not "just" a procedure; it's an appliable module, i.e., a module whose action when its name is invoked with arguments as if it were a procedure is determined by the module's member procedure named ModuleApply. The procedure convert_rtable_to_nested_list is a local member of module `convert/list`. If you want to invoke it directly, you can do

#Allow direct access to all non-export module members:
kernelopts(opaquemodules= false):
`convert/list`:-convert_rtable_to_nested_list(A, 1);

That'll work for this procedure, but it won't work in all cases because the procedure may use other module locals in ways that you can't control. This particular procedure uses no other module locals.

It would take me too long to explain the details of the argument passing of convert_rtable_to_nested_list. I think that its author should not have written it that way; it's unnecessarily complicated. That author didn't discover my simpler way. My procedure is better: It's simpler, shorter, easier to understand, and runs faster. So, I'm also a bit reluctant to describe the specifics of how some code works when it's not the best that it can be. If I had to guess, I'd guess that that procedure's author was trying to reduce the amount of garbage collection required by the procedure. However, the garbage collection seems roughly the same as mine.

You'd be "begging me too much" if you refuse to give this Answer (the immediate parent of this message) a Vote Up---it deserves several and has received none, which offends me.

@taro The order attribute specifies the order that a Matrix's (or multi-dimensional Array's) entries are physically stored in the computer's memory. Are they grouped by rows? or by columns? Numerical code that accesses the entries of a large matrix in the order that they are stored runs faster because it requires fewer refreshes of the processor's memory caches. Thus the astute programmer wants to know and to be able to set the order. There are only two possible values for order: C_order (grouped by rows) and Fortran_order (grouped by columns). As an example, define these matrices and arrays:

M1:= Matrix([[1,2],[3,4]], order= C_order);
M2:= Matrix(M1, order= Fortran_order);
A1:= Array((1..2)$3, (i,j,k)-> 100*i + 10*j + k, order= C_order):
A2:= Array(A1, order= Fortran_order):

Now apply convert(..., list) to each of these and compare. As I said above, this attribute makes no difference to the final output when using convert(..., list, nested), but it's likely to be faster for large numeric matrices that use C_order.

@taro They are essentially the same, and that was part of Tom's point. The point of his code DD is to explicitly show the order.

The English word "compare" means "note the differences or absence of differences". I've noticed that even some native English speakers think that it means "note the differences".

@taro Since you say "the code of convert/list", it's not clear to me whether you mean that you looked at

showstat(`convert/list`);

or

showstat(`convert/list` :: convert_rtable_to_nested_list);

I was only refering to the latter.

I will now show here three recursive procedures that each do the same thing as that procedure. First, you need to understand what is returned by rtable_dims(A) for any Array (or Vector or Matrix) A. Read its help page. It simply returns the sequence of ranges that specify the valid indices for A.

Second, you need to understand what A[k] returns when k is a valid integer first-position index for A and A is multi-dimensional. Experiment with this until you understand. Define a 2x2 Matrix A and look at A[1] and A[2]. Then define a 2x2x2 Array A and look at A[1] and A[2]. Notice that each of these is a 2x2 Array. That's how we can process these recursively.

Third, you need to know that Maple allows for 0-dimensional Arrays. These are a degenerate case; they simply have no entries.

So here's the first recursive procedure:

NestedList1:= proc(A::rtable)
local k, D:= rtable_dims(A);
   if D = NULL then [] #empty Array, a degenerate case 
   elif nops([D]) = 1 then [seq(A[k], k= D)] # 1-dimensional case
   else [seq(NestedList1(A[k]), k= D[1])]
   fi
end proc:

We can do two things to simplify that. The first is that there are special provisions in seq so that if A is 0- or 1-dimensional, then simply [seq(A)] returns what we want. The second is that a procedure can refer to itself (for the purpose of recursion, and for some other purposes) as thisproc or procname. The semantics of these two are a little different. Usually, thisproc is better for recursion. The procedure becomes:

NestedList2:= proc(A::rtable)
local k, D:= rtable_dims(A);
   if nops([D]) < 2 then [seq(A)]
   else [seq(thisproc(A[k]), k= D[1])]
   fi
end proc:

Finally, we can use `if` instead of if and put the list brackets just once, on the outside:

NestedList:= proc(A::rtable)
local k, D:= rtable_dims(A);
   [`if`(nops([D]) < 2, seq(A), seq(thisproc(A[k]), k= D[1]))]
end proc:

All three of these procedures do the same thing as convert(A, list, nested).

Please let me know if you understand all this, or whether I can explain something further.

@Kitonum Your "check" is flawed because 365 has a palindromic bit pattern. It's just an unfortunate choice of an example number.

Which of the two orders should be considered "reversed" is debatable. Having the most-significant bit on the left seems correct only because that's how we (in some human languages) conventionally write numbers. Having the indices start with the least-significant bit is more efficient for most computational purposes.

@Kertab24 For the time being, let's ignore the coefficient 4*mu*p and just do the integral. So, I interpret the problem as integrating sqrt(x^2+y^2) over the region 0 <= x <= B/2, 0 <= y <= b/2. The region is a simple rectangle in the first quadrant with a diagonal from the origin to (B/2, b/2). Maple will not be able to finish this double integral, as you've noticed. But I can help it by (manually!) converting to polar coordinates. I get the following, which is split into a sum of two integrals, one for the part below the diagonal of the rectangle (i.e., for y <= b*x/B) and one for the part above (y >= b*x/B):

int(r^2, [r= 0..B*sec(theta)/2, theta= 0..arctan(b/B)]) +
   int(r^2, [r= 0..b*csc(theta)/2, theta= arctan(b/B)..Pi/2]);

You and/or your mother should verify how I did that, and I can guide you through that, if needed.

The resulting expression can be simplified:

simplify(%) assuming b > 0, B > 0;

You can see that we get something somewhat similar to (but definitely not equal to) your F2 (after multiplying by 4*mu*p), but there's still the issue of the disappearing Pi. Is my interpretation of the region of integration correct? I have another possible interpretation, which I'll post shortly.

Here's another interpretation of the region: It's the triangle whose vertices are [0,0], [B/2, 0], and [0, b/2] (so, a right triangle with legs along the coordinate axes). Again, I'd use polar coordinates, and the integral is

int(r^2, [r= 0..b*B/2/(B*sin(theta)+b*cos(theta)), theta= 0..Pi/2])
   assuming B > 0, b > 0;

(The assuming clause is an essential part of that command.) This can be simplified by

convert(%, ln); #gets rid of arctanh
simplify(%) assuming b > 0, B > 0;

Once again, the result (after putting back 4*mu*p) is similar to, but definitely not equal to, F2, and there's still the Pi issue.

@tomleslie 

To avoid any possible confusion about this: The order used by convert(A, list, nested) is fixed; it's as shown by Tom above: It doesn't depend on the order attribute of A. On the other hand, the order used by convert(A, list) does depend on that attribute.

@max125 To solve a univariate inequality when one side is a monotonic function and the other other side is constant or monotonic in the other direction, change the inequality to equality and use fsolve. Do not try to use solve for this: it is an extremely complicated command with a vast number of options and modalities. Getting solve to use assumptions (such as that n is integer) is tricky (perhaps trickier than using assumptions with any other command) and hit-or-miss. Since  fsolve solves this problem easily and efficiently, what's the point of using solve?

The function 1/(n+1)! is not entirely monotonic (using its analytic-continuation redefinition as 1/GAMMA(n+2)). It's monotonic for n >= 0. VV failed to note this, and the equation 1/(n+1)! = 0.00001 has an infinite number of solutions for n < 0. His fsolve command just happened to search for positive solutions, somewhat accidentally I guess. It should be forced to only search for positive solutions like this:

fsolve(1/(n+1)! = 0.00001, n= 0..infinity);

@Mac Dude A Maple record is a type of module. If, as you suspect, an inappropriate number of records are being created and retained, that'll show up in the MODULE row of the kernelopts(memusage).