@Racine65 The evalf command will return a floating-point approximation. Any floating-point number can only be a rounded (or truncated) approximation here, since as Carl mentioned the exact value is an irrational number.

restart;

evalf((1/2)!);   # from double-precision evalhf, 16 places correct
                0.886226925452758052

evalf((1/2)!);   # remembered result, rounded to default Digits=10
                     0.8862269255

evalf[30]((1/2)!);
             0.886226925452758013649083741671

evalhf((1/2)!);   # double-precision evalhf, 16 places correct

                0.886226925452758052

I can't see what other form you might want here, other than the exact symbolic sqrt(Pi)/2, a floating-point approximation, or a rational approximation.

(note to self, it's a quirk that evalf((1/2)!) returns the evalhf result the first time, and then rounds the remembered result when re-executed. I'll submit an SCR as it's quirky.)

@Racine65 I already did that.

convert((1/2)!, GAMMA)

is just one command applied to (1/2)!

Here are some others.

convert(factorial(1/2), elementary);

                           1   (1/2)
                           - Pi     
                           2        

convert((1/2)!, elementary);

                           1   (1/2)
                           - Pi     
                           2        

convert(factorial(1/2), GAMMA);

                           1   (1/2)
                           - Pi     
                           2        
convert((1/2)!, GAMMA);
                           1   (1/2)
                           - Pi     
                           2        

simplify((1/2)!); # as vv noted

                           1   (1/2)
                           - Pi     
                           2        

In my experience it can often be productive to focus more on the way that symbolic manipulations occur and precisely how and when they are targeted than on the brevity of the command. But what do I know.

@dharr One of my points was that if one doesn't require the A,B,C expressions then a closer match to the originally requested form can be had with just this (eg. following your initial parfrac conversion to produce Gc2),

    coeff(Gc2,s,0)*collect(Gc2,s,u->u/coeff(Gc2,s,0));

The OP didn't specify whether he wanted to extract the A,B,C expressions explicitly.

Another point was that the distribution of the A term can be prevented, with an even closer match of the pretty-printed output, using the inert multiplication.

I understand that you already know all this, but it seems likely that at least some of it would be news to the OP.

The prettier form is displayed if your have the typesetting level set to standard.

You can accomplish that as a GUI setting, or by issuing the command
   interface(typesetting=standard):

By default it is set to extended in Maple 2017 onwards.

Download leibnitz.mw

[edit] Moreover, it seems that eval(Diff(f(t1,t2,t3),t1,t2,t2,t3),{t1=5}) may print in the prettier way regardless of the typesetting interface level. It may be that some aspects of all this were overlooked when the change to the new default typesetting=extended was done for Maple 2017.

@mmcdara Sure, before there have previously been intermittent failures to inline uploaded worksheets here. But this seems different and new.

It looks as if, currently, any Maple 2019.0 worksheet cannot be inlined here if it's saved under an rtablesize=list setting for interface (which includes the new default of [10,10]).

@digerdiga The example  int(dilog(x+1)/(x+a),x)  returns unevaluated.

@digerdiga 

dilogthing.mw

@Earl Do you mean a custom coloring by procedures, as available for the plot3d command? That uses the resulting cartesian x,y,z values of the points, rather than any values directly from the parametrization.

Here is an example where such custom coloring procedures are used to generate a color Array (insides a COLOR plotting substructure), which is then used as a replacement in the 2D circle frames.

restart;
N := 45:
g := 101:
P3:=plot3d([ cos(a), sin(a), 0],
             a = -Pi .. Pi,
             s = 0..1,
             grid = [g,2],
             colorscheme = ["xyzcoloring",
                            [unapply(0,[x,y,z]),
                             unapply(sin(arctan(x,y)),[x,y,z]),
                             unapply(cos(arctan(x,y)),[x,y,z])],
                             colorspace="RGB"]):
C:=indets(P3,specfunc(anything,{COLOR,COLOUR}))[1]:
f := proc(NN,t,C)
  local a,gg,P2,shift;
  gg := `*`(op(map(u->op(2,u)-op(1,u)+1,
                   ArrayTools:-Dimensions(op([2],C))[1..2])));
  shift := - Pi/2 - t/(NN-1)*2*Pi;
  P2 := plot([t + NN/10*(1 + cos(a)), NN/10*(1 + sin(a)),
              a = 0 + shift .. 2*Pi +shift],
             adaptive = false, numpoints = gg,
             thickness = 4):
  subsindets(P2,specfunc(anything,{COLOR,COLOUR}),c->C);
end proc:
plots:-display([seq(f(N,t,C), t = 0..N)],
               scaling = constrained, size = [700,500],
               gridlines = false, insequence = true);

Above you could use ImageTools:-Embed(op([2],C)); to see the colors in C.

The final circle frames are constructed with g*2 data points, since P3 is built with grid=[g,2]. This makes the numbers of color points represented by C match the number of points in each circle.

I don't think that there is an easy way to directly generate the 2D circle frames, using parametric form and custom coloring procedures (admitting the parameter values). By this I mean, a straightforward way, without having to construct the PLOT structure even more manually instead of via nice plotting commands.

Why not produce it once, using colorscheme say, and then generate the other frames by different rotation and shift (of the original)?

Search for the topic  dsolve,classical  in the Maple Help.

What have you done so far, for this question?

@vv Naturally, an appliable module is not necessary. I used one only because I was not sure up front whether I'd be able to make some nice optimizations and store part of them as module locals. (I'm somewhat sure that I could.)

But I'll point out that your procedure has additional flaws, because it relies on with(Statistics) executed at the top level, and references unprotected global names unquoted so it breaks if they get assigned.

BTW, I don't think that you have the right piecewise support in the PDF/CDF. The support of your example Y should be [1,infinity) but as its coded Support(Y) will return [0,infinity).  And CDF(Y,0.5) and PDF(Y,0.5) return nonreal values.

@mmcdara For clarity: You may have noticed that Support(Ldist, output=range) was already returning m..infinity , where Ldist came from a call to Distribution(Levu(...)). So one thing I was asking was confirmation about the change I made to pdf and cdf, conditional upon x<=m rather than x<0 as you had originally. (I know you'd assigned m:=0, but elsewhere in the piecewise you were using m, so I assumed you wanted it changed appropriately in the conditional.)

I presume that you mean that you now also added the Support piece to the defn passed to Distribution, which sounds fine.

I didn't have time to look at Mean.

It might be nice to speed up the sampling. It might be possible to construct an accurate rational polynomial approximation using numapprox, for the Quantile of Normal(0,1) from the Uniform(1/2,1), for use up to Digits=evalhf(Digits). So much fun, so little time.

@tomleslie The method you used would have to be modified, and does not work otherwise for all distributions which do not uniformly sample from every integer in a finite range returned.

The only thing you used the DiscreteUniform distribution for was to call Support against it. So the 1,6 supplied as argument to Distribution became 1..6 returned from Support. That is not informative because it returns no more information than was entered for the DiscreteUnitform case. And that's the only distribution this approach handles. If the dice had other than six faces then supplying 1,n to Distribution already contains the information in the range 1..n that Support could return. It's more convenient to not have to call two additional commands just to get the range.

Additionally, the range returned by Support may contain not only the discrete points with a non-zero probability. Consider this example:

restart;
with(Statistics):
dist:=Distribution(EmpiricalDistribution([2,3,9,11])):
Support(dist, output=range);
                   2 .. 11

The method you used did not utilize the PDF, but simply used seq over the whole range(s) returned by Support. So that method would not work correctly for this distribution. Since the range returned by Support is not being used in conjunction with something that provides the probabilities (eg. PDF, etc) then it serves no great purpose here. It may even give a slightly misleading impression that the method works for a broader class of example.

I am not claiming that Support doesn't do its job for other distributions. But one of my claims is that the range returned by Support does not make this method work for any broader class of distribution.

So Support doesn't add generality here, and returns only information about the uniform range that is already directly available from what is entered.

I don't think that Tom's implementation is incorrect or wrong. But I also think that it doesn't provide what was already shown, more simply. I was explicitly asked for my opinion, so I've given it. My opinion is no great big deal.

@sand15 I'm not sure I understand what kind of opinion you're looking for. Please note that I used EmpiricalDistribution in a Comment on my own Answer in this thread before Tom used it and in exactly the same fashion. (Actually, before anyone else used it in this whole thread. No prize wanted.)

Perhaps that indicates my judgement on its use here? Clearly it allows us to deal with the admixture of uniform distributions with finite support. Carl demonstrated adroitly that -- by also using the PDF for weighting -- the non-uniform case can also handled (as expected) via EmpiricalDistribution. That Answer by Carl is the most general result in this thread to date, and uses Statistics commands.

Note that Tom's use of Support above only serves here for the uniform case, and as such is merely an abstruse way to generate the range 1..6, IMO. Otherwise the approach is just what I'd already posted, using the EmpiricalDistribution in the same way. I had discounted this use of Support because it gave no extra functionality or generality, and was just a roundabout way to produce the ranges (from the sequence 1,6 rather than the range 1..6 directly). But it doesn't do anything special such as, say, work for the non-uniform case.

@erik10 Here is something for the (potentially) missing entries, and this kind of example.

Download sample_freq_all.mw