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

Please stop posting separate and duplicate Question threads for this example.

If you encounter additional syntax problems (2dmath, etc) then please put them in Comments/Replies here, instead of spawning entirely different Question threads.

Perhaps you are trying to obtain the following:

Download maple1.mw

What is the argument that is supposed to be passed to the f operator, inside the definition of the r operator? You have it as merely f, stand-alone. Is that supposed to be f(phi), f(theta), or...?

Also, check for missing multiplication signs. I detected a few.

I am unsure whether the brackets are all placed as you intend.

@quoteswindy0 

In Maple you assign some value to a name using  :=  not just the = symbol.

I deleted it, as a duplicate of the earlier Question's line. I used the particular moderator facility with the drop-menu item labeled "Duplicate".

I had previously politely asked the submitter (twice) to stop posting separate duplicates of the thread, and instead to add any additional details or followups in the earlier thread.

At least one other duplicate of the thread had been previously deleted (and accompanied by the mentioned kind of request).

Please don't repost this in additonal, separate Question threads.

Instead, please put your followup queries and additional details in Replies/Comments in this thread.