You should use the Grid package to parallelize a long sequence of integration or differential equations computations.

Threads:-Seq requires the computations to be thread-safe, and that is not true for computations that leverage int, limit, dsolve.

But the Grid package will allow each computation to run in wholly separate kernels. (Since many such computations are not "small" or very, very quick then the coarse granularity is less of an overhead penalty.)

If you don't want a floating-point number then don't use evalf here.

But keep in mind that applying the exp command an integer won't result in a "whole number". So for general (eg. exact rational) inputs you might find yourself in the position of your previous Question. Ie. you may have to choose between receiving a single float result or receiving an exp call as answer.

Of course we do not yet know what kinds of input you intend on passing (via the text entry), because you haven't told us.

If your issue is that you would prefer another notation for the floating-point result (eg. 4560.0 instead of .456e4 , etc) then please say so. Or even if you would like the closest (rounded) integer, etc. Please explain precisely what kinds of input and output you want.

This is so similar to your previous question that it is unhelpful and unproductive to post as two separate Question threads,  since it splits the detsils and the answer content. In future please add such close followup examples as Reply/Comment on the original, instead.

If you always want Maple to attempt floating-point evaluation then wrap it in a call to the evalf command. 

Eg,

    Do( %Result = evalf( ln(2)/Do(%Text)  )  );

For your particular example you could also simply replace ln(2) with ln(2.0).

Which of these ways you chose depends on how general you want it.

(There are also some cases --likely rare -- where keeping the ln(2) and using evalf might incur less chance of numeric roundoff error. I doubt it will make much difference to you here.)

Part of your question is about whether fsolve will be able to handle the large expression (so large that it won't prettyprint in full).

Are you trying to compute eigenvalues, by doing numeric rootfinding on the characteristic equation?

If so, then why are you not doing a straight eigenvalue computation using the Eigenvalues command (possibly after applying evalf, if the Matrix has no floats or is not yet of type numeric)?

The active lowercase sum command is outright the wrong command for this example (as given). As given, it can attempt a symbolic summation, which is generally not a good idea in the presence of the floating-point number in the exponent.

It would be relevant to see whether one needs both the floating-point exponent as well as sum (not add), to get the crash.

Using float exponents is actually not a great idea more generally. It certainly shouldn't be used as an easy way to get floating-point evaluation. Better would be use of evalf, or perhaps even a float coefficient.

Of course it is some kind of bug if Maple locks up and crashes on the very same example in 2D Input but not 1D plaintext code.(I will submit a bug report.)

You might also try with the right context-panel closed. It might possibly be related.

Personally I think that it could get sticky if the numer,denom pair didn't do any normalization (and special cases could make life more difficult).

But here is a start for what I suspect you may be after:

I include an example with numeric coefficients, ie. a fraction. [edit] It splits rational fractions, suitably. Carl's Answer's original code did not do this.

Download numden.mw

I also wrote it so that the factors sin(z)^(-b+r)*cos(z)^(b-r) would get split (if present in the ostensible numerator, ie. unless they were also raised to a negative power), as the leading term is determined lexicographically. Replace the sign business with a check for positive if you prefer. Ie,

proc(ee::`*`) local c,n,d;
       (n,d) := selectremove(e->not type(e,`^`) or op(2,e)::positive,ee):
       c := frontend(content,[n],[{`*`},{}]);
       n*denom(c), denom(c)/d;
end proc:

It's not clear to me what kind of 2D plots you want. So I will make a wild/creative stab at it.

Perhaps you would like an animation of the contour plots (level curves on the 3D surfaces for y evaluated at each k value). Perhaps you will see an idea in the following (with contour lines only, or filledregions).

(The odd piecewise used in creating the 3D surface plots is there just so that all the surfaces will have a disconnected point at the maximal height, so that they all use the same range for the y-gradient colorscheme.)

cont_anim_idea.mw

You can simply use the add command.

Download Untitled_ac.mw

I'm not sure whether this will be of partial use.

The idea is that the 2nd column of the Matrix does better than the 3rd.

Download ext_ascii.mw

I do not know whether the expression V below is right, because I do not know whether this substitution for 0.6 in your M is right, or even whether M is right. (It may not agree with what Reuben has mentioned.)

I replaced 0.6 (which presumably stands in for a/L) with the parameter name p.

But this may still show you some numeric rootfinding and related plotting methods.

Download par_roots.mw

In my Maple 2015 it appears as if the numpoints option of SurfaceOfRevolution is only controlling the values used for the (blue) function curve, whose appearance you have suppressed by passing the showfunction=false option.

And since that detail also appears to be controlled (overridden) by the functionoptions choice, then I don't really see much merit in how it uses the numpoints option.

I do see an effect from the following, however, by temporarily adjusting the "default" for the grid option.

(I suspect that you may find that the grid values get used for the number of points used for the independent parameters in cylindrical coordinates. Hence they may serve the natural purposes.)

Again, this is in Maple 2015.

Download Surface0fRevolution_ac.mw

Member vv's nice method of substitution of the floor call by a name might be modifed, so that isolve finds integer solutions for the dummy name rather than having to pepper the new formula with values from an ad hoc range.

It handles at least these two examples, with only one substitution equation. I'm sure that it could benefit from robustification.

I displayed the intermediate piecewise result, since it helps illustrate how some progress was made (you could also evalf that piecewise, to see it even more clearly).

Download solve_uni_floor.mw

Another choice -- if you want to rotate each figure separately -- is to use the viewpoint option.

And, once again, a crude way to slow down the animation (including its gif export) is to repeat frames.

You might want to consider a single color (with glossiness and lighting) instead of shading=zhue, if you plan on exporting to .gif format.

Download FiguresEspace_ac.mw

The extrusion is done using POLYGONS substructures (rather than GRID or MESH, say), so I don't think that you would be able to get a surface with wireframe grid directly.

You can use overrideoption to get various other styles that are relevant for POLYGONS, though. This affects the CURVES as well as the POLYGONS.

You could use subsindets if you wanted to target just the POLYGONS and leave the CURVES alone (if your choice would be valid for them and otherwise alter them).
 

Download extrude_style.mw

Here I've re-used the code from the MathApp itself so as to retain the aspect ratios and relative placement per frame (and a scaling procedure PP to unify the frame view).

One of the few changes I made was to allow the randomize seed to be passed to the Reset procedure, which affects the shuffling randomization of the colors.

Download fib_anim.mw

I used repeated frames to slow it down. If you have a animated .gif player which allows you to adjust the speed then there's no need to use repeated frames.