@Tamour_Zubair It's not really clear what you're trying to accomplish.

Could it be something like this?

evalf[15](Int(p*cos((1/2)*p+(1/2)*q)/(p^2+q^2)^(1/2),
              [p=0..1, q=0..1]));

                       0.553945861053642

Do you know a numeric value for the unknown t?

@Carl Love The stock EscapeTime command constructs an Image (or an Array of values) with a B&W layer of values based on the number of iterations required to escape (or possibly another layer, of abs value).

It does not classify & colour the values according to the root to which it converges -- as requested by the OP.

Somewhere I have a modified and reasonably fast version that does that... but I'm quite pressed right now.

@Rouben Rostamian  Here's one way to implement such conversions (just the double-angle, not a full trig combine) in the other direction, optionally recursing.

convert_double_angle.mw

(Sorry, this site isn't letting me inline the worksheet.)

@Rouben Rostamian  You have not specified in advance what you want to happen in general. I gave a piece of code for the examples supplied so far, and suggested it might be further adjusted.

The crux of my code snippet was to selectively freeze/veil some of the trig calls present in the expression, using foldl and frontend. It need not be combine that actually applies some conversion rule -- I was just continuing on with the theme. (It may be possible to turn powers of some trig call into an unsimplified product of "distinct" terms, for which certain rules might be more readily recognized...)

The original question thread was about elementwise applyrule.

Perhaps you could put your double-angle query (characterized in full) in its own Question thread (possibly branched from here).

And perhaps you could put your half-angle query (characterized in full) in another thread (possibly branched from here). It's quite different in nature.

Providing more general examples and expectations up front helps avoid the coding version of the whack-a-mole game.

Let's consider your last example. You haven't specified precedence of intended rules for that direction, so there ambiguity in the example. Starting from your,
   4*sin(x)^2*cos(x)
it was not clear that one should produce,
    2*sin(x)*sin(2*x)
over, say,
    2*(1-cos(2*x))*cos(x)
(Sure, you've since stated which you'd prefer. But a clear characterization up front would be helpful.)

@dojodr You are the one who asked for the symbolic solution, so only you know what you wanted to do with it.

Here are some alternatives:

Download solve_ex2b.mw

As demonstrated above, you could numerically solve (fsolve) for n if all the other parameters are substituted with numeric values.

Or you could plug such numeric values for the parameters into the more symbolic solution ans.

So you might not actually need the symbolic form ans. (You asked about such a solution, which is why I showed how one such might be obtained programmatically. Only you know why you requested it.)

If you do want to deal with that symbolic solution then you cannot simply "disregard" the LambertW or another part of the symbolic expression that you might not fully understand or enjoy.

The command LambertW is a special function that expresses a solution to a special kind of equation. You probably are familiar with other special functions that express other mathematical relationships, eg. sin(x), cos(x). But because some others are so familiar you may overlook/forget that they're made-up names that act as stand-ins for the more complicated mathematical relationships.

@Rouben Rostamian  One could tweak this kind of thing,

Download trig_comb_sep.mw

There are interesting examples where a shortest (simplest) form can be attained by applying combine after repeatedly and selectively freezing only some of the trig terms. (Somewhere I have a variant of a "crusher" appliable-module which -- expensively -- tries combinations of such things, in a search for a shortest form.)

@mmcdara Increased memory use can be a consequence of running multiple computations in parallel. It's not necessarily a consequence only of using multiple kernels in parallel.

Even when you run multiple threads in parallel (in the same kernel) they might each get some local allocation. It depends on the nature of the computation. I just happen more often to use Threads for numeric Array computations that can often each be done "in-place" on specific portions of a preassigned hardware rtable container. So usually I don't happen to see additional memory consumption according to the number of threads. But that's just due to the kinds of computations I more often do.

I don't think that I can act in-place when using Grid, and I've also noticed a marked slowdown if a passed rtable if "too big". But sure, often there is a natural give-and-take between speed and memory consumption.

It's hard to make general statements: much of all this is problem specific.

@mmcdara The Grid package uses distinct instances of the Maple kernel (engine) for each node, with no cross-pollution of memory or assignments. Thus the issue of thread safety of the code is ameliorated.

The Threads package uses the same instance of the Maple kernel (engine) for all threads. So any code which relies (even indirectly, via whatever Library commands it calls) on global state is potentially thread-unsafe. And thread-unsafety cascades. So, for example, any Thread-ed code that calls symbolic-definite int is thread-unsafe because limit is thread-unsafe.

Many (if not most) important Library commands for symbolic computation are thread-unsafe. The situation is better for kernel builtin commands, but those are a minority.

Hence I typically use Threads only for purely numeric code that I can also run under evalhf or Compile. That is to say, code the calls few (if any) commands for symbolic computation.

@rlopez Thanks, Robert.

Download hyp_tangVC.mw

@Mariusz Iwaniuk Ingenious.

Paraphrasing, and using Maple 2021.2,

integral_ac.mw

Since the OP seems to have used Maple 18 (in which Sum doesn't take formal as an option),

Download integral_ac_1802.mw

@C_R For your following example I wan't sure whether you wanted to 1) turn either expression into the other, or 2) show that they are equivalent. All under an assumption, of course.

Here's both, under the wider assumption r>=-1.

Download some_simp_ex.mw 

On the chance the you were actually trying to make ee1 turn into ee2, here's a more ad hoc and step-by-step explanation of what I did above. I say "ad hoc" because it contains assumptions placed manually on r+1 and r-1, whereas in the above worksheet I tried to make it more programmatic, deriving those assumptions on terms r+1 and r-1 (multiplicands in the factored radical) from assumptions like r>=-1 or r>=1 say. A wholly ad hoc solution to a problem like this no better than merely writing out the desired form by hand.

The idea is that simplify can pull out factors from the radical (under suitable assumptions). But collapse of the factored form back to r^2-1 gets in the way. So an approach is to replace factors by their frozen names, and place the corresponding assumptions of positivity on such (if appropriate). Making that replacement more automatic and less ad hoc is icing.

Download some_simp_ex_notes.mw

@C_R You may use any of the following.

Download Simplify_exp_with_roots_02_ac.mw

I prefer not to use the 2D Input that looks like,
   0<r<1
because it gets parsed as  0<r and r<1   and I prefer to avoid lowercase and here.

sidebar: I have seen instances where calling is((rhs-lhs)(eqn)=0) does better than is(eqn) for eqn some equation. That step may not always have been done automatically (at least historically), and simplification-to-zero is sometimes easier than reduction to a pair of forms accepted as equivalent.

Duplicates threads about this code will be flagged as such (and may be deleted).

If you have additional problems with correcting the code then you could describe those here, in Reply/Comments, instead of adding wholly separate and unconnected additional discussion threads.

@Ronan It looks as if you might have accidentally saved your own packages to that DirectSearch.mla file at some time in the past.

One way that could happen is if you used `savelib`, and it was writable and first in `libname`. 

This is one reason why I prefer to store to .mla files only by using LibraryTools:-Save (not savelib) and specifiy the library file destination explicitly.

You may wish to (remove and) reinstall a clean instance of DirectSearch v.2.