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.

Gonzalo: It will be trivial, although tedious if you're not a good typist, for YOU to type the three pages of Algol code given in the linked PDF into a plaintext file or a Code Edit Region in a Maple worksheet. After that, it should take an hour or less for one of us to convert it to Maple. The code is quite straightforward, and translating it to Maple should be trivial.

@Mo_Jalal The plot of any continuous function can be done by precomputing some points, like you've done. I don't see any benefit to doing it that way. 

You've computed points on -80..80 but only plotted on -20..20. Is there a reason for that discrepancy?

@Reshu Gupta Change the dsolve command to this:

sol:= dsolve(EQ union IC, numeric, maxmesh= 2^16, initmesh=512, abserr= 0.4e-3, method= bvp[trapdefer]):

The plots will take significantly longer to produce (1-2 minutes), but you will get them.

@Carl Love And here's an idea for representing the terms more compactly.
 

Download PolyDeconSorted.mw

@ogunmiloro In the initialization you defined C[f], but in sse you used C__f. Of course, both usages must be spelled exactly the same.

You've ignored advice that I gave you for an earlier Question about this same problem: Use option maxfun= -1 in the dsolve command. This will avoid all the "cannot evaluate" errors.

Making these changes, the optimization command will return with "no improved point could  be found." I can't help you with that at the moment. It's not due to a syntax error. Rather the problem either requires some fine tuning or it's intractable.