For fun, here's another way to get a result in terms of Psi (although, fwiw, it goes funny if assuming n<0).

You can also get a Psi form by directly converting that hypergeom call. I don't know how to do the reverse conversion.

Download int_examp.mw

Heavy-handedly,

(I'll ignore that eval(f,x=0) produces 0 directly.)

Supplying the view option does not specify the range for the independent variable.

Either of these, where the input range for x is specified, work fine.

plot((x^3 - 4*x^2 - 9*x + 36)/(x^3 - 9*x), x = -3 .. 3,
     color = red, view = [-3 .. 3, -5 .. 5]);
plot((x^3 - 4*x^2 - 9*x + 36)/(x^3 - 9*x), x = -3 .. 3,
     color = red, view = -5 .. 5);

If you omit the x-range argument then plot will try to figure something out based on the expression -- but that doesn't utilize the supplied view option.

The view option only specifies how to restrict the display of the computed plotting data. It does not specify how that data should be taken.

Below I use printf, but it's just as easy write to a file by using fprintf.

You can interject any extra lines of text (or newlines) that you want.

Do you really need to create and store all of Fs at once, as opposed to merely checking that each entry of Es does not meet the criteria of being in Fs!? Are you using all Fs for something else? That's unclear, from your wording.

[edit] I keep the way you create the sets, below, since I cannot tell whether you use them for anything else later on. My main point is that the fprintf command is a convenient tool for writing your results to a text file, which was the question asked. 

Download gprintf.mw

Those two piecewise are different from each other when t<0.

You'd have seen that if you'd plotted a range that included negative values for t.

Download pw_compar.mw

A heisenbug is no fun.

As an example that arose while poking at your problem, the following produces FAIL for me,

restart;
IntegrationTools:-Indefinite:-RationalFunction((-3450*exp(2)*_z+210*exp(4)*_z-4*exp(6)*_z-24250*exp(2)+2085*exp(4)-76*exp(6)+exp(8)+17500*_z+100000)/(-10*exp(2)*_z+25*_z^2+exp(4)-50*exp(2)+250*_z+625), _z);

                       FAIL

But when I attempt to trace or debug it (via stopat), it goes into a recursive loop.

restart;
trace(IntegrationTools:-Indefinite:-RationalFunction):
IntegrationTools:-Indefinite:-RationalFunction((-3450*exp(2)*_z+210*exp(4)*_z-4*exp(6)*_z-24250*exp(2)+2085*exp(4)-76*exp(6)+exp(8)+17500*_z+100000)/(-10*exp(2)*_z+25*_z^2+exp(4)-50*exp(2)+250*_z+625), _z);

Naturally that makes it tricky to figure how how it proceeded when it produced FAIL, which would be useful here.

I notice that this procedure can do this call, when in that recursive loop,

showstat(IntegrationTools:-Indefinite:-RationalFunction,28);

IntegrationTools:-Indefinite:-RationalFunction := proc(f, x, $)
local n, d, q, b, e, const, answer, tmp, z;
       ...
  28       answer := Main(tmp,x)
       ...
end proc

A technique used within some routines under int, is, etc, consists of storing (up front) a FAIL result for a call to a procedure that might eventually induce an identical call to itself. If this is performed prior to the first call, and if a suitable check for that value is made upon re-entry, then infinite recursion errors might be prevented. That can be important because they can be un-trappable. This is also a way in which a second attempt by the user can side-step the problem and proceed to another internal method which might be successful.

Some kinds of memory-related session dependent results have been tamed by the "new" lexicographic set ordering (which can help when, say, using indets to pick off names.) But some kinds are still lurking, due to ordering of terms in sums (or products).

I saw some mapping of action over sums in this int example, but I don't know for sure whether that is a problematic source of memory/session dependent behaviour here.

It goes amok when trying to compute this,

is(1+1/(-exp(exp(exp(3)))-2*I)*x, real) assuming x>0, x<infinity;

Error, (in type/complex) too many levels of recursion

The recursion is something like this:

(AndProp:-IntersectLines, 16): return thisproc(res minus map2(op,4,changed) union map(lp -> ...,changed))
	[{real, LinearProp((exp(exp(exp(3)))-2*I)/(exp(exp(exp(3)))^2+4)^(1/2),RealRange(-infinity,Open(0)),1)}]

Here are results for those two sets of parameter values, as obtained via the NAG library routine d01amc (included in Maple and accessed below).

Basically, I am wrapping your integrand in Maple's Re and Im, and invoking evalf(Int(...)) on those separately. I stuffed that together using functional programming syntax, in the attached below.

This is about as small an error tolerance as it'd allow me. Raising working precision of the integrand's evaluations (only, using a custom proc wrapper) didn't seem to alter the result.

If you are unable to attain these same results in your Maple version then try relaxing the error tolerance (ie. increase the epsilon option tolerance).

These results are computed quickly, in less than 1/5 of a second on my machine. They agree with your exact formula more closely than do the 3rd-party quadrature results you provided.

Download d01amc_ex.mw

The code I used is a short way to do the following, which might appear more legible to you:

evalf(Int(Re(eval(P,[k0=18.47,r=2,z=0.19])),
          k=0..infinity,epsilon=0.3e-8,method=_d01amc))
+ I*evalf(Int(Im(eval(P,[k0=18.47,r=2,z=0.19])),
          k=0..infinity,epsilon=0.3e-8,method=_d01amc));

One way is to perform a change of variables, manually.

Download Question_for_maple_primes_6_acc.mw

Without having to rely on visual examination of the plot for a starting point, we can find the first root to the left of zero as well as the first root to the right of zero.

Download tworoots.mw

For expressing the four roots explicitly in terms of radicals,

ans := [ solve(x^4-x^3-3*x^2-x+12=0, x, explicit) ];
simplify(ans, size);

or, for floating-point approximations of the four roots,

fsolve(x^4-x^3-3*x^2-x+12=0, x, complex);

I think that it would be much better to not make those assignments at all(!), and to use eval(...,[...]) to evaluate other expressions whenever you need to utilize those particular values. That would allow you to do subsequent symbolic manipulation without having to unassign. I think that is decent practice, if done in a usual and sensible manner. For example,

Download usual.mw

I don't really recommend the goal that you've described (of first assigning, and then symbolically manipulating expressions containing those assigned name, without having to unassign) whether you use the methodology below or some alternative.

In my opinion the following is using Maple is a very backwards manner. (If you do manipulations of more complexity you might have even more tricky hoop-jumping to do.) 

Download wickedness.mw

You might notice that the following direct use of plots:-odeplot (with mode=log for axis[1]) undersamples and renders a coarser curve in the lower range, as compared with plots:-semilogplot. I can't tell whether that's an issue for you since you haven't bother to provide your full example.

Download ode_semilog.mw

Are you looking for this distinction, which is documented on the Help page for arctan?

Download arctan.mw

You don't need the Embedded Plot Component in order to simply plot them all together, with the plots being rendered at the cursor's current output location.

For that all you need is,
    plots:-display(plotlist);
or, within a procedure call that returns something else,
    print(plots:-display(plotlist));

Here are those two ideas: pdisp.mw

In contrast to the above, a Embedded Plot Component allows you to set a fixed location in your document. That way, you can replace with other plots later on, programatically, and they will all appear in the same location as earlier, not matter how many times you repeat. You could also do that whenever some procedure of yours gets called. The key thing is that the plots are rendered in the same location, overwriting what was there before. This can also help save space, so that your worksheet doesn't get cluttered or scroll as much.

If you have some other usage scenario then it would be best if you could describe it precisely. (I can think of some other scenarios, but guessing can be inefficient.)

Your problem was not in evaluating the entries of x (ie. each Vector in your aVectorList). It was due to not accounting for AddVector being reused each time through the loop.

[edit] I gave a 1-liner alternative below, using seq. (Other alternatives are possible, using map[2], etc, including the one Carl has subsequently provided in his Answer.) Since a terse one-off replacement doesn't provide insight into what went wrong for you originally, I wrote all the rest with the hope of explaining by example.

Download Mutable_ac.mw