@DJJerome1976 

I agree with DJ Jerome's skepticism about RealDomain. I am particularly skeptical about RealDomain:-solve. That's why I said to put

with(RealDomain, `^`);

rather than

with(RealDomain);

into your initialization file. The former will overload only the `^` operator, which is enough to accomplish everything discussed in this thread and which doesn't introduce any problems that I know of.

@Alina8faq Yes, there is a way that you can use I as a variable in Maple 13. First, choose a symbol to use as the imaginary unit. Let's say that you choose J (although it need not be a single letter). Then give the command

interface(imaginaryunit= J);

Now you are free to use I however you like.

Even though you use the I with subscripts, it is still confusing to algsubs. But all will be okay if you give the command above.

@Alina8faq Yes, there is a way that you can use I as a variable in Maple 13. First, choose a symbol to use as the imaginary unit. Let's say that you choose J (although it need not be a single letter). Then give the command

interface(imaginaryunit= J);

Now you are free to use I however you like.

Even though you use the I with subscripts, it is still confusing to algsubs. But all will be okay if you give the command above.

@ANANDMUNAGALA Please note that I have significantly updated the procedure since you posted the above Reply.

@ANANDMUNAGALA Please note that I have significantly updated the procedure since you posted the above Reply.

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

@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?