@mmcdara I don't understand what you are talking about, with respect to a "personal license" having effect here. What precisely do you mean, and how do arrive at your conclusion?

The Open in New Window menu choice appears upon right-click of a Help link in Maple 2017.3 onward, but not if you are still using Maple 2015. Even in Maple 2017.3 that works for me in both a text Help-url link in a Worksheet as well as a Help cross-reference in an open Help page -- but not to the page names in the left-panel tree. That's what I wrote before.

I would agree that it would be an improvement to allow opening of Help pages in separate windows, upon right-click on the names in the left-panel tree (in addition to how it currently already works for url links).

Also, with regard to what Christopher2222 has (inaccurately) claimed, one can in fact launch two instances of Maple's GUI that don't interact with each other. Each can then open its own Help viewer separately. One way to get this effect is to add   -standalone   to the call to the Maple executable in the launcher. (That undocumented option causes each Maple Standard GUI to use its own Java vitual machine instance. I like using this because a crash in one does not crash the other.)

If I right-click on a cross-reference link within an open Help page then it offers me the choice Open in New Window, which works and opens a new window.

That also works if I right click on a Help hyperlink in text in an open Worksheet.

I don't get any right-click menu for the topics in the Browser menu (left-panel).

I used Maple 2021.1.

Is that adequate for your needs? (With effort it might be possible to concoct a procedure that does it...)

There is a "Multiple Help Windows=" item in the plainttext file in which GUI options are stored (on Linux that is file ~/.maple/2021/maplerc but on MS-Windows its a maple.ini somewhere I forget...). But editing that rhs to be "true" doesn't seem to have any effect, anyway. This might be a holdover from the Classic GUI (Standard Java GUI was introduced in Maple 9).

Calling your procedure assigns to global names r1,r2, etc. It is better to use indexed names r[i] where you have r declared local. Assigning to concatenated names within a proc is a bad habit.

Also, your procedure uses several names unprotected by quotes, and will have problems if they are assigned at the higher level.

Waterfall_ed.mw

Tell us what numeric values you used for r, z, and k0, when you performed numeric quadrature.

What result did your other software obtain for that?

ps. I changed your Post into a Question.

@Joe Riel The OP's very original code almost appeared to be an attempt to deal with some (incorrect, if purported) notion of all Vector element references as being merely references to an indexed name, as if explicit evaluation might help. And so we eventually got around to discussing element access, which (naturally) is by value.

Your example seems (to me) to have more to do with the distinction between top-level evaluation of assigned (global) names and 1-level evaluation of assigned local names than it has to do with Vector entry access.

When I wrote, "When entries of a Vector are accessed individually they get evaluated" I meant, naturally, that they are accessed by value and evaluation is like normal (for the running environment, be it top-level or within a procedure call). I made this statement only because the OP had tried to fix his original problem by apply eval at the point of accessing the Vector entries.

@The function Examples which exhibit this problem can get tricky to simplify, after the poor solution is generated. For example, a fortuitous constant might be found and added which allows the result to factor nicely.

Download Question_for_maple_primes_6_accc.mw

I won't bother doing trying to automate that, because finding a better methodology for dealing with the unexpanded integrand seems better than dealing with an unfortunate expansion in an answer. There are already heuristics inside int that could handle this example -- if they were properly applied.

@Ronan There are several problems with your answer:

a) The text input has a syntax error, and won't execute if pasted in as 1D code

b) With the syntax corrected, that call to solve returns implicit RootOf's. It seems likely the OP is trying to avoid the implicit RootOf's, if searching for exact solutions.

c) With the syntax corrected, that call to fsolve returns NULL (empty result) because all four roots are complex and nonreal. It seems likely the OP is trying to avoid that NULL result, if searching for approximate solutions.

@eric2399 

The Question was about how to add multi-line input within a single Paragraph or Execution Group -- given that pressing the Enter key causes execution.

You have shown a way to insert a distinct, new Execution Group below the current input, but that is not what was asked here. Your Answer does not address the question that was asked.

The answer was already given: use Shift-Enter instead of just the Enter key. (Or Shift-Return instead of just the Return key, if that's how it's labeled on the keyboard.)

Upload and attach your problematic worksheet, using the Green up-arrow in the Mapleprimes editor.

@Anthrazit 

Download CompareUnits_ac.mw

@Anthrazit Could you provide examples of the "unit conversions and a lot of other stuff" that the Units:-Standard package allows but the Units:-Simple package does not?

@Mac Dude This is often done like,

    indets(A, And(name,Not(constant)))

so that names like Pi are omitted.

@Anthrazit The questions you appear to now be asking now are not directly related to the original problem.

The original problem was with producing distinct instances (alternatively, snapshot copies) of AddVector each time through the loop -- so that they could be separately put into results as distinct Vectors. The original problem was not in evaluation of entries in x a Vector of aVectorList (or lack of it). If you understand that now, great.

The questions you're posing now relate more to examples like the following. (These are not like you original, in which the entries of the Vectors of aVectorList were all just numbers.)

Download rtableeval.mw

So, in your original problem you could also implement a solution using map(eval,AddVector) or instead of copy(AddVector), since both of those happen to produce a distinct new Vector. But as I mentioned in a followup comment, I don't think that either of those is a best approach here.

@Anthrazit In none of these examples (your first, and all mine) do the entries of AddVector retain any connection to the original entries of the Vectors in aVectorList.

Even if you changed any entry of either Vector in aVectorList inplace, after-the-fact, it still would not affect the entries of the Vectors in results.

One easy way to explain that here is because the Vectors in aVectorList are of length/dimension 2, while those in results are of length 4. They simply cannot be the same structure. (Here, this is also true at any length. But here it helps us realize it.)

When entries of a Vector are accessed individually they get evaluated. You get the scalar value, not a reference to it. Your original problem was not due to references to the entries of any Vector in aVectorList, or any way of accessing those.

As I mentioned before, your original problem was not related to mutability, per se. It was more due to using name AddVector as a reference to the same Vector each time through the loop. That re-uses the same Vector each time through the loop, which does not help you get distinct Vector structures into results.

By the way, another way to fix your original example is to augment the results by
   copy(AddVector)
instead. But that method only works properly because you happen to act on all the same entry positions each time through the loop. To be safe, in general, you'd also want to zero out all entries of AddVector, each time through the loop, say using ArrayTools:-Fill. Otherwise AddVector could be dirty with some stale, prior values, and in consequence so might be the copy. I did not mention this way earlier because it is unnecessarily more complicated, and has no special merit.

Download Mutable_acc.mw

@mmcdara This is relatively poor solution, since it incurs additional and unnecessary floating-point roundoff error (and loss of accuracy in the result) for some ranges of exponent.