Speaking of efficiency, I really ought to have pulled the FitIntensity(ToGrayscale(A)) out of that loop...

SetBackground:=proc(A::Array, C::string)
  local g,i,p,T;
  uses ImageTools;
  if not type(A,'Array(:-datatype=float[8])') then
    error "expecting an Image for the first argument";
  end if;
  if nops([op(2,A)])<>3 then
    error "expecting a color Image with exactly three layers";
  end if;
  p:=[ColorTools:-Color(C)[]];
  g:=FitIntensity(ToGrayscale(A));
  for i from 1 to 3 do
    T[i]:=Threshold(g,0.001,method=both,low=p[i],high=0.0);
    T[i]:=T[i]+GetLayer(A,i);
  end do;
  CombineLayers(T[1],T[2],T[3]);
end proc:

It would be neat to have a highly efficient color mapping command, to swap out pixels in an Image of a given color (or those "close enough" in some color space) with another color.

@itsme I submitted a bug report on the day it was posted.

@Joe Riel Since there is only one distinct instance of the particular SUM in the kernel's simplification table then it suffices here to sort the polynomial, which affects other references to it.

restart;

ee := sqrt(1+x+x^2);

                                             (1/2)
                                 / 2        \     
                           ee := \x  + x + 1/     

ff := tan(1+x+x^2);

                                     / 2        \
                            ff := tan\x  + x + 1/

sort( 1+x+x^2, [x], ascending ):

ee;

                                          (1/2)
                              /         2\     
                              \1 + x + x /     

ff;

                                  /         2\
                               tan\1 + x + x /

@Christopher2222 In Maple 2016 a call to simplify(...) made from the top-level does a final step of (additonally) doing what simplify(...,size) does. But when called from within a procedure such a plain call to simplify(...) does not do that.

Either behaviour can be overridden by forcing an (undocumented) option in the call. Ie,

restart;
interface(prettyprint=0):

dint := proc (a, b, c, d)
  simplify(subs(b = d, int(a, b))-subs(b = c, int(a, b)),
           applysimplifysize = true):
end proc:

dint(exp(x^3),x,1,2);

    (1/6)*(I*3^(1/2)-1)*(GAMMA(1/3, -8)-GAMMA(1/3, -1))

restart;
interface(prettyprint=0):

dint := proc (a, b, c, d)
  simplify(subs(b = d, int(a, b))-subs(b = c, int(a, b))):
end proc:

dint(exp(x^3),x,1,2);

  -(1/6)*GAMMA(1/3, -8)+((1/6)*I)*GAMMA(1/3, -8)*3^(1/2)+
   (1/6)*GAMMA(1/3, -1)-((1/6)*I)*GAMMA(1/3, -1)*3^(1/2)

simplify(%, applysimplifysize = false);

  -(1/6)*GAMMA(1/3, -8)+((1/6)*I)*GAMMA(1/3, -8)*3^(1/2)+
   (1/6)*GAMMA(1/3, -1)-((1/6)*I)*GAMMA(1/3, -1)*3^(1/2)

This is a slightly tricky area, because it seems as if quite a few people seem to think that simplify(...,size) is designed to do everything that (non-top-level, or as in previous releases) plain simplify(...) does, yet with additional compactification. The help pages makes it clear that's not the case.

Under IntegrationTools:-Definite:-Integrators:-FTOC:-FindDisconts (after trying for an antiderivative) the call to discont fails hard because it doesn't know how to handle 2-argument GAMMA.

acer

@Kitonum Nicely done. I did this before I saw your response, but I may as well throw it in...

E_T := (2/mu-2/r)*exp(-r/mu)*Pi^2;

L1:=map(u->`if`(u::polynom,content(u),1),
        map(numer,[op(E_T)])):
new:=`*`(L1[])*`*`(zip(`/`,[op(E_T)],L1)[]);

This is a good question. It's a shame that Maple offers a literal subscript (both via keyboard shortcuts and Layout palette) but no direct and easy way to get a literal superscript.

acer

You may not have to utilize lprint. You should be able to copy and paste the particular 2D Input for which you had done the conversion, for use later on.

Note that the fact that you converted one a particular instance of the 2D Input T[4]^0 does not mean that you can subsequently type in T[4]^0 as input (1D or 2D) any place afterwards and have it be valid as the LHS of a colon-equals assignment statement.

Download msubsup.mw

@KCPower If your code is only going to display plots of the results then it may be quicker to strive for less accuracy in the numeric integrations. For example you could try evalf(Int( ..., epsilon =1e-5 )) instead of  int(..., numeric).  You could also try forcing a particular  method, and I have a hazy recollection that method=_d01akc might do faster as long as the accuracy is not too strict and the max intervals is high enough for convergence at the higher frequencies. Fiddling with this is what I lack time for now, sorry.

Time and time again it has turned out that the most effective way to speed up such code is focus on improving the efficiency of the serial (unparalellized) version.

I see several serious innefficiencies, offhand. I expect at least a few orders of ten speedup are possible. Unfortunately I have almost no time for it right now.

@taro It's the layout that I mostly have problems with. I described some of the issues in an earlier comment above. Another problem is that the central panel is too narrow. The Editor window is also too narrow.

Also, the layout changes are mostly just a re-skinning of the layout -- a degradation IMO, and nothing I've ever seen anyone here request. But several bugfixes and improvements that have been asked for previously (sometime multiple times) have generally not been made.

Inappropriate or misspelled tags cannot be deleted.

The Search is weak, in multiple ways.

Here is some Math typeset by the "Maple Math" button in the Editor, which inlines a generated image with coarse rendering and other problems: Even five years ago there were better solutions for math on web pages.

2D plots in uploaded worksheets still get gridlines added, unless the person explicitly adds the option to turn it off in the plotting command. Is that bug still present in MapleNet, or is this site still using a version that's 10 years old?

Plots in uploaded worksheets look very poor and coarse (innappropriate jpeg export?), and lose modern lighting effects that make them look good in Maple itself.

@eclark Sorry I don't know details of size restrictions on Maple Cloud uploads. I don't think that it allows uploading a sheet compressed (zip, gzip, etc).

There may be a small chance that the plot structure could be made smaller (eg. float[8] data in GRID or MESH instead of listlists) but we'd have to see it, or code that made it preferably. Are the frames from displayed Graphs?

If your target audience is small then they could try the free Maple Player. It allows manual rotation of a free-standing inlined 3D plot. (But it also allows you to even set things up so that others can execute some code behind embedded components, though the code can't be entirely secured from inspection.)

@tsunamiBTP I cleared off all cookies and things and (for that reason or some other) I can usually now upload, yes, also using Chrome.

However sometimes my Windows 7 Chrome cannot even submit a Comment/Answer, at all, even without uploaded attachment. The Submit button just does nothing. This doesn't always go wrong, though. It dosn't happen on my up-to-date Firefox on Windows 7 though, or on my Chrome on Ubuntu.

I really find it hard on my eyes to read anything here, in the new format. Perhaps I'll have to stop.

@mmcdara  I think that the responders here all understood the math, up front. You asked why it went wrong, and so I tried to explain how it does so. I submitted a bug report earlier yesterday.