Context can be everything. If I recall correctly, the earlier queries were about obtaining equations/results for integrals with a mix of symbolics and floats, and not immediately about some end-goal of doing numerical quadrature to obtain purely floating-point results. So, IntregrationTools:-Expand might have been the answer to the question then asked, but the context in which it was asked may have not reflected the actual final goal.

For example, here your integrand contained symbolic M. Even though you said it represented a constant numeric value, your question did seem to be all about getting an integration result with M a symbol.

Yes, this suggestion has been made a few times before.

See ?anames , with which you could probably create such functionality in a Maplet.

From ?AudioTools,Create

- The output from the Create command is an Array (unless the initial data was
  returned as the output, in which case it may be a Matrix or Vector) with
  dimensions appropriate to the duration, rate, and bits specified. It will
  also have three numeric attributes describing the data: rate, bits, and
  sub-format. The latter is currently always 1, corresponding to the PCM
  sub-format of the WAVE file format.

So, it looks like that is the only currently supported sub-format. Maybe someone designed it this way, so that it wouldn't change so much if more formats were supported later on.

From ?AudioTools,Create

- The output from the Create command is an Array (unless the initial data was
  returned as the output, in which case it may be a Matrix or Vector) with
  dimensions appropriate to the duration, rate, and bits specified. It will
  also have three numeric attributes describing the data: rate, bits, and
  sub-format. The latter is currently always 1, corresponding to the PCM
  sub-format of the WAVE file format.

So, it looks like that is the only currently supported sub-format. Maybe someone designed it this way, so that it wouldn't change so much if more formats were supported later on.

This below is 32bit Maple 13.01. Maybe a bug in evalf/hypergeom?

> I1:=Int(1/(x^4+3*x^2+1)^(p),x=0..infinity):
> IntegrationTools:-Change(%, x=1/2*(-6+4*t)^(1/2),t):
> ans:=combine(value(%)):
> pTst:=1+1/10^10:
> A1:=eval(I1, p=pTst):
> A2:=eval(ans, p=pTst):
> kernelopts(printbytes=false):
> for i from 1 to 10 do
>   10*i, evalf[10*i](A1 - A2);
> end do;
                                           -9
                                 10, 0.1 10

                                           -19
                                20, -0.2 10

                                    30, 0.

                                           -39
                                 40, 0.4 10

                                           -49
                                 50, 0.3 10

                                           -59
                                 60, 0.1 10

                                           -68
                                70, 0.10 10

80, -0.000043100778980475202289559448650365183794976646416770678663251463908\
    06893607091

90, 0.0003985432986810029112486364642370807310758666020965936515406264232268\
    09829555793182667554

                                           -99
                                100, 0.3 10

> forget(evalf):
> for i from 1 to 10 do
>   10*i, evalf[10*i](A1 - A2);
> end do;
                                           -9
                                 10, 0.1 10

                          20, 0.00061962896747697547

                     30, 0.000519554061779471171523031423

                                           -39
                                 40, 0.4 10

                                           -49
                                 50, 0.3 10

                                           -59
                                 60, 0.8 10

                                           -68
                                70, 0.10 10

                                                     -58
                      80, 0.7927865459866016139635 10

90, -0.003995587273719920581114317826509075565412958849153092247883367953094\
    219987113628638112880

                                           -99
                                100, 0.3 10

> ans;
     (-p)  1/2
1/2 9     6    hypergeom([p + 1/4, - 1/4 + p], [1/2 + p], 5/9) sin(Pi p)

    GAMMA(-p + 1) GAMMA(- 1/2 + 2 p)/GAMMA(1/2 + p)

> convert(ans,StandardFunctions);
     1/2  (1/2 - 2 p)
1/2 2    3            hypergeom([p + 1/4, - 1/4 + p], [1/2 + p], 5/9)

    sin(Pi p) GAMMA(-p + 1) GAMMA(- 1/2 + 2 p)/GAMMA(1/2 + p)

This below is 32bit Maple 13.01. Maybe a bug in evalf/hypergeom?

> I1:=Int(1/(x^4+3*x^2+1)^(p),x=0..infinity):
> IntegrationTools:-Change(%, x=1/2*(-6+4*t)^(1/2),t):
> ans:=combine(value(%)):
> pTst:=1+1/10^10:
> A1:=eval(I1, p=pTst):
> A2:=eval(ans, p=pTst):
> kernelopts(printbytes=false):
> for i from 1 to 10 do
>   10*i, evalf[10*i](A1 - A2);
> end do;
                                           -9
                                 10, 0.1 10

                                           -19
                                20, -0.2 10

                                    30, 0.

                                           -39
                                 40, 0.4 10

                                           -49
                                 50, 0.3 10

                                           -59
                                 60, 0.1 10

                                           -68
                                70, 0.10 10

80, -0.000043100778980475202289559448650365183794976646416770678663251463908\
    06893607091

90, 0.0003985432986810029112486364642370807310758666020965936515406264232268\
    09829555793182667554

                                           -99
                                100, 0.3 10

> forget(evalf):
> for i from 1 to 10 do
>   10*i, evalf[10*i](A1 - A2);
> end do;
                                           -9
                                 10, 0.1 10

                          20, 0.00061962896747697547

                     30, 0.000519554061779471171523031423

                                           -39
                                 40, 0.4 10

                                           -49
                                 50, 0.3 10

                                           -59
                                 60, 0.8 10

                                           -68
                                70, 0.10 10

                                                     -58
                      80, 0.7927865459866016139635 10

90, -0.003995587273719920581114317826509075565412958849153092247883367953094\
    219987113628638112880

                                           -99
                                100, 0.3 10

> ans;
     (-p)  1/2
1/2 9     6    hypergeom([p + 1/4, - 1/4 + p], [1/2 + p], 5/9) sin(Pi p)

    GAMMA(-p + 1) GAMMA(- 1/2 + 2 p)/GAMMA(1/2 + p)

> convert(ans,StandardFunctions);
     1/2  (1/2 - 2 p)
1/2 2    3            hypergeom([p + 1/4, - 1/4 + p], [1/2 + p], 5/9)

    sin(Pi p) GAMMA(-p + 1) GAMMA(- 1/2 + 2 p)/GAMMA(1/2 + p)

This does sound like the performance jump when going from hardware to software float computation.

It's hard to make suggestions that could help, without knowing more of the particulars. Perhaps not all of the computation requires the higher precision, and Digits could be raised/lowered at various points in the code, to reflect that.

It's also (slightly) possible that an adjustment to kernelopts(gcfreq) might help a bit. (See ?kernelopts and ?gc ) The intermediate "software" floats are all garbage that has to be managed and collected.

As far as wish lists go, it might help for Maple to get some quad-precision compiled (external) numeric routines, to make the Digits=17..31 region of computation be more practical.

This does sound like the performance jump when going from hardware to software float computation.

It's hard to make suggestions that could help, without knowing more of the particulars. Perhaps not all of the computation requires the higher precision, and Digits could be raised/lowered at various points in the code, to reflect that.

It's also (slightly) possible that an adjustment to kernelopts(gcfreq) might help a bit. (See ?kernelopts and ?gc ) The intermediate "software" floats are all garbage that has to be managed and collected.

As far as wish lists go, it might help for Maple to get some quad-precision compiled (external) numeric routines, to make the Digits=17..31 region of computation be more practical.

Note that the above only ever assigns to any entry's storage location with its sorted index. So you might save memory by using storage=sparse or storage=sparse[n] for the minimal n.

Note that the above only ever assigns to any entry's storage location with its sorted index. So you might save memory by using storage=sparse or storage=sparse[n] for the minimal n.

The help page for fprintf ( see ?fprintf ) describes %g in the section entitled Formats.

The help page for fprintf ( see ?fprintf ) describes %g in the section entitled Formats.

Are you after this thing?

with(Student:-Calculus1):
P1:=VolumeOfRevolution(y^2, 4, y=0..2, axis='horizontal', output='plot',volume2options=[color=red]):
P2:=SurfaceOfRevolution(0, x=0..4,axis='vertical', output='plot'):
plots:-display(P1,plottools:-rotate(P2,0,Pi/2,0));

Are you after this thing?

with(Student:-Calculus1):
P1:=VolumeOfRevolution(y^2, 4, y=0..2, axis='horizontal', output='plot',volume2options=[color=red]):
P2:=SurfaceOfRevolution(0, x=0..4,axis='vertical', output='plot'):
plots:-display(P1,plottools:-rotate(P2,0,Pi/2,0));

I mentioned the Layout palette, since it seemed to me that it provided what was requested. I figured that I'd misunderstood the request, since he didn't respond.

But the way, the "prepost" item is a little odd. You can use it to generate super/subliterals for some of the (right) positions but with the left super- and subscripts  instantiated as indexed value and algebraic power.

It might be more flexible if there was an all-rounder, a literal-script entry in the Layout palette which allowed for tabbed-fill-in of all six supported positions (with all six being literal sub/superscripts).