@Kitonum I mentioned it mostly because it affects whether the integral is -infinity for t<0, which happens with a factor of s^(5/2) in the numerator but not with a factor of s^(11/2).

Using Maple 2015.2, I get,

restart;
int((1/2)/(s^(1/2)*GAMMA(1/2)*(t^(1/2)-s^(1/2)))*(s^3),
    s = 0 .. t, AllSolutions);

                           { -infinity        t < 0
                           {
                           {     0            t = 0
                           {
                           { infinity         0 < t

restart;
int((1/2)/(s^(1/2)*GAMMA(1/2)*(t^(1/2)-s^(1/2)))*(s^6),
    s = 0 .. t, AllSolutions);

                                   infinity

@Kitonum Did you perhaps mistype that s^(5/2) subterm?

Your insistence in using floating-point coefficients before doing your symbolic integrations, even though it would be trivial and reasonable to turn them into very short exact rationals and the benefits have been demonstrated before, is four-alarm crazy.

acer

@Carl Love I assumed that it was the mostly the usual reason to use unapply -- that he was starting off with an expression (here, theta*x) obtained from another computation and not known specifically in advance, and wanted to use that to construct one or more procedures, and that also the formal parameter (here, theta) occurred in that obtained expression.

In your code you have typed the subexpression theta*x in the definition of the body of the template procedure. The needs and means will be different if that subexpression is allowed to be arbitrary and known only at construction time.

@Bendesarts On Windows the keyboard combination is Ctl-t to switch into text mode and Ctl-r to switch into 2D Math mode. See the Help topic worksheet/documenting/2DMathShortcutKeys .

If you are in the middle of some text you can actually do any of these, to toggle into 2D Math mode: Ctl-r keystroke, or Math icon, or F5 keystroke, or menubar item Insert->2-D Math .

If you are entering some inlined 2D Math in a block of text then you can switch the entry mode back to text with these: Ctl-t keystroke, or Text icon, of menubar item Insert->Text.

The menubar's "Insert" submenu also shows the keystrokes to toggle between input modes.

This seems easy to do and discover, to me.

My complaint is that the symbols are too large. At 100% zoom they are slightly too large relative to the text, by default. For default text at 12pt I prefer the inlined 2D Math at 10pt, especially for the currently used integral and summation symbol. (Of course I can also change this behaviour.) At 150% zoom level the inlined 2D Math looks better relative to the text, by default.

I'm using Windows 7 here, and for that platform I would expect much better choices for defaults.

For inlined text it would be nice to also have the easy choice of the slanted small integral and the small summation symbol, in the way that TeX/LaTeX does it for inlined math in a paragraph of text.

The relative size of text and inlined 2D Math looks worse after embedding the Worksheet to this site. The following is all from a single Workheet.

Download inlinemath.mw

@John Fredsted Does this get you the behaviour you are after, with use of uneval quotes?

restart:

G := [seq(unapply('unapply'(u*theta*x,x),theta),u in [v1,v2])];

    G := [theta -> unapply(v1 theta x, x), theta -> unapply(v2 theta x, x)]

G(phi)(x);                                                     

                             [v1 phi x, v2 phi x]

G(w)(t);  

                               [v1 w t, v2 w t]

If the cost of calling `unapply` on each invocation of `G` is concerning you may also try to get away with doing it with `subs`.

restart:                                                                     

G := [seq(unapply('subs'(theta=':-p',unapply(u*theta*x,x)),':-p'),
          u in [v1,v2])];

        G := [p -> subs(theta = p, x -> v1 theta x),

              p -> subs(theta = p, x -> v2 theta x)]

G(phi)(x);

                             [v1 phi x, v2 phi x]

G(w)(t);

                               [v1 w t, v2 w t]

@Preben Alsholm That may need to also do a preliminary protective subs of any preexisting Int calls inside u, to avoid clobbering them all inadvertantly at the final step. (And then a step to undo such a temporary shunt.)

Also, perhaps it could adjust at the end, since the trailing arguments to the collapsed Int are put into a list (I think), but not wanted that way for the final collapsed Diff.

@Preben Alsholm I wonder whether it would be useful to have an analogue to IntegrationTools:-CollapseNested, for Diff, somewhere...

@Doug Meade In Maple 2015 the 2D rendering of names  epsilon , `&epsilon;` , varepsilon , and `&varepsilon;` were changed, as documented in the Compatibility notes to that release.

It makes matters a bit more confusing that (at the time that I write this) the MapleNet used in the Online Help displays them in the old way for the online version of that page -- and so is incorrect.

In addition to the compatibility notes, the name varepsilon gets typeset the same way as does `&varepsilon;` in Maple 2015. If that is documented in the What's New then I've missed it.

There is some improvement in 2015.2 over 18.02, in the sense that rendering of typeset epsilon and `&epsilon;` have become consistent.

I'll attach some screenshots, where I get them rendered as 2D Output as well as insert them from the Greek palette.

Maple 18.02 at 150% zoom, on 64bit Windows 7, where the discrepency between epsilon and `&epsilon;` is clear.

Maple 2015.2 at 150% zoom, on 64bit Windows 7, shows that discrepency removed, albeit at the cost of incompatibility.

The above are both at 150% zoom. But at 100% zoom the varepsilon looks too much like an italic "e" to me in my old Linux SuSE 10.04. Here is is on my Windows 7, which is acceptable but not great:

And here it is on my (very old) 64bit Linux SuSE 10.04, with the varepsilon rendering too much like an "e" at 100% zoom.

I always use the GUI at 100% zoom, so the rendering of varepsilon is problematic to me. It may possibly be a font issue specific to my very old (officially unsupported version) though.

The above are all screenshots. The images are not all the same size as I've used different screen grabbers across platforms.

@iman The name `1` is used instead of the integer 1 in several places.

That occurs in the assignment to bcs2. It also happens several times in the list used for the approxsoln option passed to dsolve.

If I delete these instances of `1` and replace by the integer 1 then the dsolve calls return a new error message to the effect that 14 boundary conditions are expected but only 12 received.

You might consider switching to 1D Maple Notation for input, instead of 2D Math input., if you are having these kinds of problems with your authored code.

On the 7th line, where you assign values to some parameters, there is s=0.1 which is an equation not an assignment. You likely intended that as s:=0.1 instead.

I don't know the code for shoot, but it may not be possible to use the variable  (ie. gamma) if you don't first declare it as a local at the top-level, since Maple thinks that  (ie. gamma) is a special constant. I suggest that you simply use another name instead.

acer

I may have to recant.

The reason why I originally expected neither method to work was that (as Carl mentions) names in the :: type do not evaluate. That's related to why we don't uneval quote Matrix when using x::Matrix(square) , as it will not call the Matrix constructor. That contrasts with checking the type by calling type(M, 'Matrix'(square)) say.

But a formal parameter of a procedure is, effectively, used in the procedure like a constant rather than a (variable) name whose value may vary. (Perhaps this is what Christian's comments are about.) I'm referring here to parameter dim of createModule1.

So it may be that the different behaviour of createModule1 and the original createModule2 is technically correct.

But at least I got to report that other bug with the invalid substituion...

subs(y=(2,2), proc() :-y; end proc); # I'd like to see an error message here
                            proc() :-2, 2 end proc

> dismantle(%);

PROC(11)
   EXPSEQ(1)
   EXPSEQ(1)
   EXPSEQ(1)
   EXPSEQ(1)
s=0x7fb5a5b203f0, unexpected EXPSEQ member of MEMBER
Error, (in dismantle/dump) object at address is invalid

Thanks to John for the invigorating examples.

@Carl Love The version with dim declared local (as vv had done) is better, by way of being safer.

The slightly modified createModule2 example below, in which the global :-dim is utilized within the constructed module export det, will go wrong if dim does not scope out to a local for that subs call being made inside det.

The local dim declaration could be part of either createModule2 (as vv had it, and as I had it in my unapply workaround above) or the constructed anonymous module.

If you run the code below, without dim declared local within createModule2 or the constructed module, then you should be able to see what I mean.

restart:

dim:=13.5:

with(LinearAlgebra):

createModule1 := proc(dim::posint)
    module()
        export det;
        det := ((x::Matrix(1..dim,1..dim)) -> :-dim*Determinant(x));
    end module
end proc:

createModule1(       2 ):-det(IdentityMatrix(2));

                              13.5

createModule2:= proc(A::Matrix(square))
uses LA= LinearAlgebra;
     module()
     local dim;
     export 
          det:= subs('dim'= LA:-Dimension(A), (x::Matrix(dim))-> :-dim*LA:-Determinant(x))
     ; 
     end module
end proc:

eval(createModule2(Matrix(2)):-det);

          x::(Matrix(2, 2)) -> :-dim LinearAlgebra:-Determinant(x)

createModule2(Matrix(2)):-det(IdentityMatrix(2));
                              13.5

And I've submitted a separate report that the following crashes the kernel. An error message about invalid substitution would be gentler.

p:=subs(y=(2,2),proc() :-y; end proc);
                          p := proc() :-2, 2 end proc

p();
Execution stopped: Stack limit reached.

@John Fredsted That the second one does not work.

I have submitted a bug report.