It's not clear to me what you are trying to accomplish, since there is only one free variable in the example you gave.

Could you explain what you want to be the second independent variable? I am going to guess that you mean the upper value of the index of summation.

Download contourplot_sum.mw

Or possibly this (though not so interesting...)

plots:-contourplot(sum(BesselJ(n,r),n=0..floor(i)),
                   r=-10..10,i=0..5,grid=[51,201],
                   contourlabels=false,
                   filled, coloring=["Navy", "Orange"]);

My oracle came up with these.

You'll have to judge whether the author's of these textbook examples might consider the solutions to be real, or what you think of squaring (or apply exp to)  both sides of an intermediate equation, etc.

Download examples_of_odes_that_do_not_odetest_ac_pt1.mw

[edit. 23/12/2020] Partially addressing a followup example. (End-points can be examined separately.)

# 3647
restart;
ode :=diff(y(x),x)=2*(x*sqrt(y(x))-1)*y(x):
ic  :=y(0)=1:
sol :=dsolve([ode,ic]):
res :=odetest(sol,ode):
solve(simplify(res)) assuming real;
                 RealRange(Open(-1), infinity)

Here is another way that happens to work for this example.

Using allvalues on the RootOfs is a better/stronger idea. It's a shame that a single solve call cannot find the exact real solution directly, even with its explicit option (and possibly with some mechanism to denote realness).

Download solve_exp_poly_ex.mw

There are also some slightly more general but uglier variants which utilize frontend (as if temporarily freezing the exp call) and pass an inequality to solve to denote realness.

There is the iscont command. Its Help page is linked from the "See Also" part of the discont command's Help page.

There will always be problematic examples, however.

Download iscont.mw

There is also fdiscont, which can be finicky but may offer some recourse for examples for which symbolic analysis is problematic. It doesn't go well on your piecewise example, though.

The first thing is that you have a syntax mistake. You have,
    S*`union`(T intersect R);
which ought to be,
    S union (T intersect R);
It's possible that was an implicit multiplication mistake made in 2D Input mode.

Download logic_set.mw

There are several ways to do this. Here is but one of them,

Download CAP13CombinatoireQuestion_ac.mw

I'm not sure why you want them in a set at the end (instead of a list or Vector). When you put them into a set you may lose duplicates.

You can remove all output (including plots) from a worksheet as follows:
  Maple 2015:  File->Edit->Remove Output->From Worksheet   (Alt-e  v  w)
  Maple 2020:  Evaluate->Remove Output from Worksheet  (Ctl-d)

That message about storing large data mostly refers to the output of large Arrays/MatricesVectors/rtables, when they are printed as output. I don't know how to reuse such stored results upon Close/Re-open. (It is stored in some text-encoded reference in the XML of the .mw file, potentially large.)

The preference for the large-computation-autosave-thingy is in a popup that apepars when you click the "Confirmation Dialogs" button on the Tools->Options->Interface popup tab. 

If you are using Explore then the embedded plot will lose the axis and viewing-range properties you put on it using the right-click menus, whenever the plot is subsequently updated.

Instead, you can use the view option in the actual plotting command to fix the visible range so that it remains static for all updates of the Sliders..

You may also use the sprintf command can construct strings. I think that often looks more legible than a complicated cat call.

You can escape double-quotes within the format. There are various ways to do it, depending on whether you want to pass allmembers as name or "allmembers" as string.

When you parse the result the inner double-quotes should survive. (Of course, parsing these results reuires Property to be a member of module NODESteelProfiles_I .)

g := "NODESteelProfiles_I:-Property";                                              
                        g := "NODESteelProfiles_I:-Property"

sprintf("%s(%a)", g, "allmembers");

             "NODESteelProfiles_I:-Property("allmembers")"

sprintf("%s(\"%a\")", g, allmembers);

             "NODESteelProfiles_I:-Property("allmembers")"

sprintf("%s(\"%s\")", g, "allmembers");

             "NODESteelProfiles_I:-Property("allmembers")"

The inner double-quotes are escaped within the string results. You don't see that when your merely print it, but you would if your used lprint.

The subsindets command does syntactic substitution. That is mostly similar to how subs works, and as the Help page explains by default subsindets will utilize subs to perform the replacement.

It is intentional that subsindets does not do a full evaluation by default. That allows multiple syntactic substitutions and structural manipulations to be performed in sequence.

You can compare subsindets with evalindets. You could also compare with calling the indexed command name subsindets[eval].

Entering an expression at the top-level does an evaluation (unless you use special syntax to control that). That's true even if done on something that subsindets or subs had returned unevaluated. It's also true if the expression is used for an assignment statement.

There should be nothing highly surprising in the following:

Download subsindets_evaluation.mw

As for int and your example involving exp(various ln calls, etc) it is much easier to snipe than to code. It's a difficult subject and there is no perfect algorithm for discerning when and whether to simplify all possible examples that might benefit as well as succeed in decent time. There is always room for improvement.

It seems to me that there are two kinds of issue worth considering here. One is the construction (binning, etc) of the data, and another is the plotting and visual rendering.

I'd like to look at the first part later, which I think could be done with some efficient procedure(s). There may be some related bits of functionality within the ImageTools:-Scale command. But I don't have time to study those R commands at the moment.

Here are a couple of alternatives for the plotting/rendering part, using techniques that are actually 2D.

You might still experiment with the nb size, naturally.

2D_density_plot_acc.mw

I'm not sure offhand why that happens. But you might convert the Matrix (or Vector...) to listlist before construction of the procedure.

Download CG_Matrix_opt.mw

No, in your examples you do not have to declare the parameters of the inner procedure as locals of the parent procedure.

That is true whether you use arrow notation or proc...end proc. That is handled automatically. 

The situations in which it does matter include:

1) You use `unapply` instead, to create the procedure.

2) You are using `subs` to replace a parameter name within a procedure (thus used like a template). In this case I usually use a name beginning with double-underscore, since nobody should assign to that. This name is being replaced with something hopefully nicer, anyway.

ps. You showed two examples. The local `x` in the first example has no bearing on the `x` used as parameter to the arrow procedure. The second example is slightly better because it doesn't contain a wasted, unused local declaration. Otherwise the two act the same.

In you example you don't want assuming to be called until the replacement procedure (that forms the third argument passed to subsindets, which does the replacement) itself gets called.

You want assuming to be invoked within the body of the replacement procedure, not as part of the creation of that procedure.

Put it another way, you want the assuming called during the calls to the replacement procedure, rather than when that procedure is merely defined. When that procedure is defined the names present when it later gets called are not yet available.

One way in which this can be attained is by use of brackets in the code. I also show some other ways below.

Download subsindets_assuming.mw

I don't what all your other examples might be. But you may wish -- at some point -- to distinguish between the argument to csgn and the names in that argument (if it is not just a name).

There are several problems in the code. One of the main ones is that the procedures use the first argument f as if it were an operator/procedure, by applying it. But your example passes an expression instead of an operator/procedure.

Check for mistakes. (Vary the fixed step-size h, etc.)

The is the RK4 procedure, but you could edit the Euler version similarly.

The plotting below involves some recomputation (via RK4) that is not strictly necessary. I kept to what I perceived as the spirit of your original, and made no attempt to optimize plotting, etc. (I can think of at least four decent ways to accomplish better efficiency there: storing/returning all the iterates, memoization in a few ways, etc.)

Download rk4new_ac.mw