@oxy Even using a variety of assumptions, I cannot simplify the expression or convert it to StandardFunctions.

@spradlig RealDomain does make your plot work the way that you want, and it does make 4^(1/2) evaluate to 2. Did you try it? If you want these behaviours to be the default, then include this line in your initialization file:

with(RealDomain, `^`):

@spradlig RealDomain does make your plot work the way that you want, and it does make 4^(1/2) evaluate to 2. Did you try it? If you want these behaviours to be the default, then include this line in your initialization file:

with(RealDomain, `^`):

It will work for the plain numeric expressions, but not the plots.

It will work for the plain numeric expressions, but not the plots.

Thanks for taking a look at this issue. 

A fundamental problem here is that there are far too many combinations (in the OP's application) to store in memory all at once. They need to be generated in "blocks" and written to disk. (In my code comments, you'll see many references to the blocks.) My producer/consumer model was actually in three stages, each with a separate thread:

Generate combinations (producer) => Filter (middleman) => Write to disk (consumer).

Handling things in this blockwise fashion and doing the file I/O is why my code is so lengthy.

I've subsequently improved this (but I haven't posted it) so that the Generate stage is subdivided using the Task model. The Filter stage is trivial to parallelize with Threads:-Map. I don't see any point to parallelizing the Write unless one were using multiple disk drives.

In the improved version, I use combinat:-rankcomb and combinat:-unrankcomb to find the starting place of each Task within the canonical ordering of combinations. That way they can be generated iteratively and not all of once.

I am pretty sure that the reason that your parallel version is faster in total CPU time is not better memory management but rather that generating the combinations iteratively via combinat:-nextcomb is substantially more complicated than generating them recursively. Take a look at combinat:-Combinations:-Successor, which is what nextcomb calls.

@dimasje There is unfortunately no command SumTools:-Expand analogous to IntegrationTools:-Expand, although obviously the analogous operation is valid. I only temporarily exchanged Int and sum for the purpose of using Expand. Obviously the exchange is not valid in general.

@dimasje There is unfortunately no command SumTools:-Expand analogous to IntegrationTools:-Expand, although obviously the analogous operation is valid. I only temporarily exchanged Int and sum for the purpose of using Expand. Obviously the exchange is not valid in general.

@dimasje Now would you please re-enter the corrected expression in ordinary keyboard characters so that I can cut and paste it?

@dimasje The two expressions are not equal---the one with sums is the ln of the product.

Would you please reenter your expression using normal keyboard characters? The "Maple Math" format in MaplePrimes is extremely difficult to read.

Is the orbit length known? Your use of the parameter Nit suggests that you know the orbit length when you call the procedure. If you know the length, then you don't need to check whether it reaches the initial point. And if you don't know the length, then there is no need for the parameter.

@candy898 Yes, the two answers are the same. Mine is collected with respect to y, and yours is collected with respect to x. See ?collect .

@Kaare112 That's a good point. I'm glad that you see it that way. See my Answer below.

I must not be understanding your question correctly. Why not just go to the second line, where you set mu, rho, and g, and just change them?