I removed my Answer because I hadn't understood from the OP's initial wording that he wanted a periodic result.

Up vote for Tom.

@mmcdara What you have done is actually no different.

You are simply illustrating that in your Maple 2015 the act of printing Vector A causes a full evaluation of the entries.

Your "trick" to utilize names v||i instead of v[i] does not solve his goal in such later versions. The names in the entries are slightly different, but the behavior in question is the same.

The actual entry stored in A is still the same name.

Download trick_not_2015.mw

In more recent versions of Maple (2018.2 and onwards, say) the printing behaviour changed, and merely printing Vector A still shows the (whichever) unevaluated name.

@Carl Love I was thinking the same, but trying to not be pushy about it.

@Kitonum I have two queries about your Answer:

 -- Do you have suggestions about computing the full range the OP requested, t=0..2*Pi ?

 -- Are you sure about the integrand you used?

@CygnusX1 Did you see the transformer_with_short_CacDS.mw file earlier, in which the running best results can get printed, as DirectSearch runs? It also shows that you force-stopping the computation and still gettting access to the best result's parameter values.

The DirectSearch:-GlobalSearch command has a help page that shows some options for the command. Global optimization is often not easy, especially in the case of several variables (and possible nonlinear objective), and more so if you really need the very best result and not just the best possible within a given number of objective evaluations or time limit.

You could also try rewriting the inner maximization problem to also utilize DirectSearch (instead of the Optimization package and workarounds for it that may slow the objective or prevent it from being evalhf'able). You might be able to get by with your original expression (no frills, even with that abs call). I didn't optimize the inner problem for speed because I didn't know originally that you would be doing that later attempt of global optimization with more variables.

You might also be able add options to DirectSearch so that it did not try to polish results to high accuracy, focusing on attaining coarser results more quickly.

@NeraSnow The reason that you example is not documented in the Help page for Topic Gcd is that this behaviour is not specific to only that command.

The rebinding behaviour of the with command can affect most any name, depending on the particular names of the exports of the package being loaded. The behaviour you describe as "sneaky" is mostly the whole point of the with mechanism.

And it is documented in the Description of the with command's Help page. Ie,

   When with is called with the name of a package as its argument, it binds
   the names exported by the package to the global namespace. This makes
   the exported names available to the interactive user at the top level of the
   Maple interaction loop.

As mentioned, you can continue to utilize the original global name via the colon-dash syntax. And you are not forced to call with. You could, alternatively, utilize the explicit long-form names of package exports. You could also utilize with to load/bind only some select package export.

@CygnusX1 Here is a reworking of your previous Reply's attached worksheet, with some workarounds:
 - to get it to run (here, Maple 16.02)
 - to preserve the best result found so far, if it accidentally bails early with an error

transformer_with_short_Cac.mw

This may be a good time to let you know (or remind you) that in the multivariate case the NLPSolve command provides local optimization, not global optimization. The final results in the above attachment is not showing convergence to a global minimum; I can be a lower objective with the DirectSearch add-on global optimization package. Ie, it can find these values for Zstub and the Zmv[n], which I'll here pass to find the inner maximizing f-value.

NLPSolve(Gammaproc(f,7.94978033705770, 4.08965197980607, 6.12109691708771,
                                8.21891823501128, 13.1493049297548, 25.2038185509781,
                                41.9752157544411),f=f1..f2,maximize);

   [0.00299878124323753), [f = 4.10000001048156]]

transformer_with_short_CacDS.mw

(For the univariate case of the inner maximization w.r.t f I'm just using NLPSolve, which is defaulting to its global branchandbound method. It was the outer multivariate minimization for which I needed the global optimization package DirectSearch.)

@Preben Alsholm Thanks. I was afraid that might happen in v.12, that no iterations performed error.

In the best scenario it might be enough to have the f-range not be symmetric about the non-differentiable cusp-line, so it isn't used as the initial f-value. In worse cases there might be a few other old workarounds to try.

And maybe I can get to that actual version 12 on some host.

@CygnusX1 From what you write, it reads as if some of the things being passed to unapply -- in one of your problem scenarios -- might actually have been values instead of unassigned names. (I suggest that in such a case it would be more prudent to figure out why the error was thrown, than to bluntly just remove the option.)

I will try to find time to look at your revised worksheet.

Thanks for the version confirmation. It's quite understandable that the kind of code you have gotten used to writing for v12 might work ok in v.2019. That's likely not as much of a concern. More tricky is when I need/want to rely on a workaround for your difficulties that might rely on some codebase fix made in the past.

Another consideration is that several responders on this forum will utilize Maple language enhancements introduced only in the past decade. The back-and-forth while ensuing syntax errors (when run in much older versions) are ironed out can be entertaining but time consuming.

@CygnusX1 Please upload and attach your actual worksheet. I can't do so much with incomplete code snippets that doesn't contain all needed to run stand-alone. I can't really tell what new concoctions you're trying with seq(p||s,s=1..N).

Also, please confirm whether you are in fact using Maple 12 (release 2008). It is fourteen major releases out-of-date, and there have been so many corrections and enhancements in the past fourteen years; it can really make a difference in how best to respond.

I am curious why you removed the numeric option from this line of code:
   Gammaproc := unapply(Gamma,[f,Zstub,seq(Zmv[n],n=1..N)],numeric):
I had that option there for a reason. But my query really is this: what are the grounds for removing it!? Hopefully it's not because you didn't happen to fully understand it.

@tomleslie That exact same variant evalc(expr) (followed by wrapping its result in a call to simplify) was part of my prior answer.

I gave it as an alternative to a longer step-by-step approach, under the hypothesized context that the unknown x might be presumed by the OP to be purely real.

So, I agree that it is a straightforward approach. But I'm confused as to your central point, and perhaps I'm missing something. When you write, "It is often simpler", what are you comparing it to?

There is a recursive example (due to Helmut Kahovec) in this old post.

@Kitonum That procedure doesn't account for the case that the entries of the input lists might themselves have operands. In such cases it can produce the wrong result, eg.

restart:

CartProd:=proc(L::list({set,list}))
local n;
n:=nops(L);
if n=1 then return L[1] else
[seq(seq([op(p),l], l=L[n]), p=thisproc(L[1..n-1]))] fi;
end proc:
Warning, (in CartProd) `p` is implicitly declared local
Warning, (in CartProd) `l` is implicitly declared local

LL:=[seq([seq(x[i,j],j=1..3)],i=1..2)];

   LL := [[x[1, 1], x[1, 2], x[1, 3]], [x[2, 1], x[2, 2], x[2, 3]]]

CartProd(LL);

       [[1, 1, x[2, 1]], [1, 1, x[2, 2]], [1, 1, x[2, 3]], 

       [1, 2, x[2, 1]], [1, 2, x[2, 2]], [1, 2, x[2, 3]], 

       [1, 3, x[2, 1]], [1, 3, x[2, 2]], [1, 3, x[2, 3]]]

[edited] Some (but not all) kinds of correction to that procedure might also benefit in performance by memoization such as adding option remember,system, depending on the entries.

@Carl Love I'm away from a computer for a while, but I believe you, and it's interesting. Thanks! (Historically, the trig/arctrig solvers sometimes suffered from producing some extra, spurious, exact results.)

For the OP's goals, I'd mostly still give the same general advice as before, however. (And, as shown, increased working precision is one way in which the issue can be skirted, even without recourse to purely numeric fsolve).

[edit] It looks as if that generic solution involving the unspecified implicit RootOf is only valid (as a solution for JD) for some restricted range of L. But once you hit that generic implicit solution with allvalues the original fomula for JD is no longer part of what's being computed. I'm going to submit a bug report.

@Carl Love Fascinating.

I can get that -- as purely an effect of the GUI's 2D Output with typesetting=extended -- if the procedure has options operator and arrow, and the Pi/2.2 occurs with and. Then the floatPi automatic simplification kicks in at some point in the pretty-printing.

But the procedure itself seems fine.