@dharr In this case, I think that Nu stands for the Nusselt number. There are so many named parameters in boundary-layer fluid dynamics that they usually go by two-letter abbreviations.

@nguyenhuyenag The embedded assignment was introduced in Maple 2018. By using it, I was able to avoid having the same statement, vars:= indets(f) minus kv, appear both before the loop and inside the loop. That's just a stylistic preference, and has little effect on efficiency.

@ In your code, you've used a sequence theta(n) for what Calvin calls gamma(n). You've defined theta(n) as 1/(1+n), but this does not have the properties listed at the bottom of p 308: "an increasing sequence of positive numbers such that gamma(n) => infinity, gamma(n)^2*ln(gamma(n))/n => 0, and gamma(n)/gamma(n+1) => 1." So, this is your error, or perhaps one of your errors.

@ Okay, I can read the paper now. But I don't see a formal listing of an algorithm or any pseudocode. What part of the paper have you translated into Maple?

I noticed that you added a try...catch statement. What type of errors has it been catching?

@ Your Maple procedure WP declares several variables that aren't used in the code. That's a sign that you missed something. The variable a is initialized for each iteration of the main loop, but it isn't otherwise used.

Do the simplifications depend on anything that's not explicitly in the expressions being simplified? I'm primarily thinking of assume commands.

What's the value of nops(dummy_UU1)?

What's the average CPU time per simplification for the serial code? In other words, what's the number returned by

CodeTools:-Usage(map(simplify, dummy_UU1), output= cputime, quiet)/nops(dummy_UU1);

Have you tried Grid:-Map without the tasksize option?

You didn't reply to my extensive Answer to one of your other Questions: https://www.mapleprimes.com/questions/230277-What-Is-The-Conception-Of-process

Nor did you respond to the two emails that I sent you.

I spent several hours researching and writing that Answer.

@ The body of the Elsevier / Science Direct article that you linked to is not accessible without paying a fee.

Does your Maple version produce the wrong results? Or does it simply take too long? If it's the latter, I can fix it without needing to see the original. 

If this is an attempt by you to find the longest path, it won't work.

@vs140580 From the Wikipedia article "Hypercube graph", I learned that for distinct vertices u and v in HyperCubeGraph(n) there is a Hamiltonian path between them iff their Hamming distance is odd. Thus, if the distance is odd, then the length of the longest path is 2^n - 1. If the Hamming distance is even, I don't know, but I suspect there's an equally simple formula.

@vs140580 If you'd want to restrict attention to certain highly symmetric special cases, such as hypercubes, then a fast answer is possible. The vertices of HyperCubeGraph(n) can be represented as n-lists of 0s and 1s. Because of the symmetry, the relationship between any two vertices is (up to isomorphism) entirely determined by the number of positions that are different in their 0-1 representations (known as their Hamming distance). Thus, there are only n possible relationships between pairs of distinct vertices. Thus there are only n possible values for the length of the longest path.

@sand15 The issue is that Sample uses an hfloat array by default. If you map those integerizing functions over an hfloat array, the result is still an hfloat array, and thus can only contain hfloats. This allows those commands to work under evalhf. But if you use an sfloat array, as you did, then mapping those functions changes the datatype of the array, because now there's no worry about evalhf.

But if you first convert to a list, as I did, before mapping the integerizing function, it works fine. As my code shows, this is many times faster than using an sfloat array.

You asked:

• Couldn't  it be interesting that these three functions also operate on hfloats?

Yes, it is, and exploiting that fact can lead to remarkable speed gains (20X - 30X). Hardware floats can exactly represent and compute with integers under 2^50 (or so). This is one reason why the LinearAlgebra:-Modular package is so fast. For the functions that can work with evalhf, see ?evalhf,fcnlist.

@vs140580 The longest-path problem for general graphs and digraphs is known to be NP-hard, meaning that there's provably no fast algorithm for it. You need to check every path.

@mmcdara The Algol that you quoted

i:= k; for i: = i— 1while co x eps2 < p A i > 0 do

translates to Maple as

for i from k-1 by -1 to 1 while co*eps < p do

Although I haven't read through it super carefully, I don't see any typos in the Algol code.

@Mo_Jalal It would've been a worthy experiment with respect to the run time if you had restricted the computation to -20..20. But that's not what your code shows. It shows that you computed over -80..80 and then plotted over -20..20. The time to plot the points once they're computed is nearly zero.