@vv Thanks. The original problem is: 

evalf(Int(x^(x^x), x = 1 .. 6));

Unfortunately, Maple cannot evaluate it (Why?).
So I have to change the variable (x^x -> y, so diff(x(y), y) = 1/(y*(1 + LambertW(ln(y))))) manually, but Maple still cannot compute: 

evalf(Int(expr[2]/(y*(1 + LambertW(ln(y)))), y = 1 .. 6^6));
evalf(Int(expr[3]/(y*(1 + LambertW(ln(y)))), y = 1 .. 6^6));
evalf(Int(expr[4]/(y*(1 + LambertW(ln(y)))), y = 1 .. 6^6));

This is really strange. (And if one doesn't know expr₁ in advance, Maple can never simplify any of expr₂, expr₃, and expr₄ to expr₁ ….)

@acer Thanks. But I don't know why a singular simplify command is not enough here. Maybe there is still plenty of scope for improvement in Maple.

@vv You are right; such transformations are mentioned within the first link (Чебышёв, Čebyšëv, or Chebychev) in this post. But in my view, shouldn't this be done internally in Maple (just as Mma did)? (Another similar example is: integration - Does there exist a complete implementation of the Risch algorithm? - MathOverflow. Fortunately, Maple 2023 has fixed that "bug".)

@acer Thanks.
Besides, I find another way to avoid the lengthy results: 

[1/(4*a + z^2 + (z^4 + 4*a*z^2)^(1/2)), -1/(z^2 - (z^4 + 4*a*z^2)^(1/2) + 4*a)]:
int~(evala(%), z); # rather than just `int`
 = 
     [                   (1/2)                       (1/2)]
     [    / 2 / 2      \\             / 2 / 2      \\     ]
     [    \z  \z  + 4 a//             \z  \z  + 4 a//     ]
     [z - --------------------    z + --------------------]
     [             z                           z          ]
     [------------------------, - ------------------------]
     [          4 a                         4 a           ]

It seems that the putting the radical in the numerator is better than putting the radical in the denominator. (But in my opinion, this must be a bug instead of a feature.)

@ecterrab Thanks for your detailed descriptions! I shall read them later.
Recently, I read a note: https://www.12000.org/my_notes/CAS_ode_tests/reports/maple_2022_2_mma_13_2/indexchapter1.htm#x2-80001.3 (CAS Independent Differential Equations Tests - Maple 2022.2 and Mathematica 13.2). I find that certain ODEs that cannot be solved by Maple 2022.2 (yet can be solved by Mathematica 13.2.1) have been solved by Maple 2023.0, but many of them remain unsolved for the latest Maple. Will they be solved in a future release?

@vv In my opinion, Maple can "evalf" S, but cannot "evalf" s or v (at least in acceptable time); isn't this a bug?

@Thomas Richard Thanks. But since dilog is just a special case of the polylog, why can't Maple handle the expression directly? (And as @vv says, it appears that there are some unexpected limitations in Maple.)

@Christian Wolinski Thanks. But in my opinion, numerical computations may suffer from floating-point errors (theoretically or mathematically). Can Maple carry out those evaluations exactly and symbolically?

@vs140580 If you don't want to write loops, You can use: 

Statistics:-Scale(datainMatrix, center = convert(Statistics:-DataSummary(datainMatrix, output = minimum), list), scale = convert(Statistics:-Range(datainMatrix, list))

I think that what you need is just the Statistics:-Scale command: 

@nm Thanks. But I think that for comparison, using rtable is more suitable. (In other word, table versus rtable, or array versus Array.)

@acer Thanks for your detailed reply.

I'm not sure if understand this point. Of course, one may pre-allocate storage for the output and write one or more for loops, but people can, in effect, write more compact (and clearer?) codes (with neither pre-allocation nor loops) like: 

(() -> args[-1])(( … ), ( … ), ( … ), ..., ( … )); # do several operations (but put several steps on the same line), and give the result of the last one
MakeFunction(%)( … ... … ); # another way to implement sequences of commands (i.e., a compound expression) rather then fit each step on a separate line

And then simply put the inline object into (nested) seq in a user-friendly way (with less error prone?). It seems that they enable the user to focus (entirely?) on the algorithm instead of the mechanics of either creating a new structure or iterating through loops. (I don't mean that the programming infrastructure is not important. But it appears that if somebody only want to do a small task, writing large amount of code will more or less stifle the initiative and dampen the enthusiasm.)

@Carl Love Thanks.
Besides, the documentation of GraphTheory:-TransitiveReduction states that

which does not seem correct …. 

@lcz Actually, the given digraph has been reduced in advance (so the output should remain unchanged), but as you may have seen, Maple still cannot find correct results. 
By the way, the original G__0 is also a minimum equivalent graph of itself (as it does not contain any cycles). (In cyclic case, see and .) 

@mmcdara Thanks. But in newer Maple's version, it doesn't look very aesthetic:  .