When a Document Block is not in "expanded" state then it consists of a pair of Execution Groups. The output of the first is supressed and the input of the second is supressed from display. The output of the first is used as input for the second, behind the scenes in the GUI when the Block is "collapsed" = not "expanded". This scheme causes all normally printed output to be queued (as the redirected material) and only printed altogether once the first Execution Group (containing the user's command) finishes computing.

If you execute the code in either of the two collapsed Document Blocks in the attached Document you should see that the printed results for either collapsed Block are displayed in two clumps. The individual printed statements do not get printed one at a time, asynchronously. The same goes for lprint, printf, and userinfo statements.

doubters.mw

If you were to expand either one of the two Document Blocks (select with mouse, menubar "View" submenu) then you'd see a pair of Execution Groups for each, with red prompts. If you were to execute only the first of the pair of Execution Groups in an expanded Document Block then the results would display asynchronously, just as Worksheet users expect.  There is an "output redirected" comment, between the Groups, if an entire expanded Block is executed together, say using the menubar's `!!!` icon.

This is just one reason why I don't use Documents, and stick to Worksheets.

I see an expectedly close result in Maple 15.01, but not in Maple 16.00 onwards.

It may be possible to work around the issue by assigning UseHardwareFloats:=false and retaining Digits=10, without having to incur even more extra cost of higher that default working precision. (That still won't be as fast as hardware double precision at the key steps internally, of course.)

restart:                                      
with(Statistics):                             

r := RandomVariable(NegativeBinomial(3, 0.1)):

Mean(Sample(r, 10000)); Mean(r): evalf(%);    
                               101.792300000000

                                  27.00000000

UseHardwareFloats:=false:
Mean(Sample(r, 10000)); Mean(r): evalf(%);

                                  27.02560000

                                  27.00000000

@Mac Dude FYI, I included another kind of example (affecting BesselY, BesselK and perhaps AiryAi, AiryBi but not others it seems):

restart;                   
evalf( BesselY(0, 2/3*x) );
                          BesselY(0., 0.6666666667 x)

restart;                   
UseHardwareFloats:=true:   
evalf( BesselY(0, 2/3*x) );
Error, (in evalf/BesselY) cannot handle unevaluated name `x` in evalhf

kernelopts(version);
           Maple 2015.2, X86 64 LINUX, Nov 13 2015, Build ID 1087698

@Mac Dude I will submit an SCR (Software Change Request, ie. bug report).

Simpler example:

restart:

evalf(LambertW(3));

                                  1.049908895

restart:           

UseHardwareFloats:=true:                

evalf(LambertW(3));     
Error, invalid input: evalf/LambertW uses a 2nd argument, zz, which is missing

In addition to Thomas's suggestion, you could upload a worksheet in which the error occurs. Something else seems to have come before the problematic execution, since the floats are printed with more than default digits.

@Bendesarts I hope this is clear. When you reopen this sheet you should be able to immediately execute the last line, to show that P is the Matrix of data, without re-executing any of the earlier lines.

DT3.mw

@sarra How about...

Download aHH.mw

I am not seeing that error, if I paste or type it in as 1D or 2D input in a Worksheet using Maple 2015.0 on Windows 7, with the restart in either a separate or the same execution group or document block.

Could you please upload a Worksheet or Document that demonstrates it?

acer

@sarra 

Download H1.mw

@vv The conversion to exp broke for this in Maple 10.03.

restart;

kernelopts(version);

             Maple 10.02, X86 64 LINUX, Nov 8 2005 Build ID 208934

ee := 3^(-(1/2)*n)*2^((1/6)*n)-2^((2/3)*n)*6^(-(1/2)*n):

convert(ee,exp);

    exp(-1/2 ln(3) n) exp(1/6 ln(2) n) - exp(2/3 ln(2) n) exp(-1/2 ln(6) n)

simplify(combine(%));

                                       0

And,

restart;

kernelopts(version);

            Maple 10.03, X86 64 LINUX, Mar 24 2006 Build ID 222373

ee := 3^(-(1/2)*n)*2^((1/6)*n)-2^((2/3)*n)*6^(-(1/2)*n):

convert(ee,exp);

                        (n/6)  (n/2)     (n/3) 2  (n/2)
                       2      6      - (2     )  3
                       --------------------------------
                                 (n/2)  (n/2)

...with the ensuing difficulties we see in this thread.

@vv If n=s+t*I then with arbitrary real s and t we get coverage of arbitrary complex n which was the question at hand.

I doubt anyone's suggesting that Maple ought not be able to get all this easily -- I'm not.

@faisal You can send me a contact (via email) using the "Contact" button here. After I reply to that by email you can send me a longer message with an attachment, say.

@faisal If you are using Maple 2015 then it may be that you did not intend the extra (errant) space between brackets in D(F) (etainf) and that the GUI automatocally inserted it.

If you are using Maple 2015 then you could disable so-called Smart operators by unchecking the box in the preferences dialogues. See the main menubar and Tools->Options->Interface->"Smart operators". It is a bug in the Smart operator facility that it inserts an extra space between round brackets in so common a situation as the initial conditions on derivatives as expected by the dsolve command! You can disable this feature and save that preference globally, so as to cover future Maple sessions.

See also here and here.

@markweitzman That undefined result is coming out of the FTOC (Fundamental Theorm Of Calculus) method=ftoc that is one of the approaches int can take for definite integration.

By forcing the ftocms method the desired result can also attain. The difference in the methods consists (mostly) of whether the :-series and :-limit or the MultiaSeries:-series and MultiSeries:-limit commands are used.

Sorry, I do not have the time to dig down into the integration engine, to debug and figure out where it goes wrong with method=ftoc. It may be some kind of hint, that it works if the abs is turned into Heaviside up front. (It could also be related to the limits where tp=t but that is pure conjecture.)

Download MWP44_edited2.mw

@Markiyan Hirnyk  How is the answer given for that so-called precedent relevant here?