@Age Those single right-quotes are called uneval quotes. There is a help page with the topic uneval.

What you've called algebraic is usually referred to as an expression. You are figuring out that some commands like fsolve, plot, etc, accept the first argument in either opertor form or expression form.

This is a common stumbling block for new users, and you have done much better than most at figuring it out on your own.

Search for the colloquial term "premature evaluation" (alongside "Maple") for examples of others' difficulties with all this.

Why do you need to restart?

Is it because you want to undo the name bindings (to the package exports) of the earlier calls to with?

If so then instead of restart you could use unwith.

acer

Honigmelone, it's not entirely clear what your expectation and objections are here.

What parts in particular, if any, do you object to in the following. Please show your response explicitly.

restart;
assume(a(t),real);
getassumptions(a(t));
                                              {a(t~)::real}

assume(b(t),real);
getassumptions(a(t));
                                              {b(t~)::real}

restart;
alias(a=a(t),b=b(t)):
assume(a,real);
getassumptions(a);
                                              {a(t~)::real}

assume(b,real);
getassumptions(a);
                                              {b(t~)::real}

restart;
alias(a=a(t),b=b(t)):
assume(a,real);
getassumptions(a);
                                              {a(t~)::real}

additionally(b,real);
getassumptions(a);
                                        {a(t~)::real, b(t~)::real}

You seem to have saved your worksheet in Maple 18.00. Is that right?

acer

@vv I don't see why one would expect something different there.

restart;

alias(a=a(t)):

:-a(t)(t) - a(t);
                                                    0

a - :-a(t);
                                                    0

The thing you are trying to subtract is :-a(t)(t).

dismantle(a(t));

FUNCTION(3)
   FUNCTION(3)
      NAME(4): a
      EXPSEQ(2)
         NAME(4): t
   EXPSEQ(2)
      NAME(4): t

The behavior in question is in `assume`, and I don't see that `alias` has much to do with it (other than its use having obscured the details).

I'll note this too,

restart;
getassumptions(a(x))  assuming b()(x)::real;
                                              {b()(x)::real}

@gw_g It's not so much that "the author of the worksheet possibly could provide..." the ability to change paremeters and execute "...by his design". [emphasis mine]

Rather it relevant that achieving execution following changing of parameters is wholly intended to be done in the MaplePlayer via Embedded Components. That is what the Player is good for.

If you use the side panel in the Player and change its drop menu to "MathApps" and browse down (down arrow tip) you can find a variety of worksheets that provide various kinds of interactive computation.

The author of your .mws worksheets did not set up the worksheets to provide interactivity via Embedded Components. So the MaplePlayer is merely a viewer for such worksheets. And clearly the author of those worksheets which you possess had no intention of using Embedded Components since they were saved in the older .mws format which doesn't even support Embedded Components.

Complaining that the MaplePlayer does not provide any interactivity for worksheets that are not authored to provide interactivity via Embedded Components makes little sense, because Embedded Components is THE mechanism by which the Player offers interactivity and recomputation.

@terryma You are welcome.

Look at the long list of names that get printed when you execute with(MTM). All those names are then bound to various exports of the MTM package.

You can always call the original, global name using the colon-dash syntax, such as :-subs(...) for example, even if you have rebound the subs name by loading a package such as MTM.

You can also call the MTM export by using its long form name, such as MTM:-fourier(...) for example, even if you don't load the whole MTM package.

So, you can always force what you want, whether you load the package or not. The available syntax allows you to force things either way.

@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.