@Kitonum 

Explore(val(r), r=1..3);

even works in Maple 2015.
What doesn't work is  Explore(val(r), r=[1, 2, 3])

@nm 

I tried this 

restart:
sys := { D[1](F(x(t),y(t)))*dx + D[2](F(x(t),y(t)))*dy = 0, dx = diff(x(t), t), dy = diff(y(t), t) }:
infolevel[dsolve] := 4:
dsolve(sys, {x, y})

At some point I got a promising  <- 1st order linear successful and after nothing more, MAPLE is stucked somewhere.
Maybe an idea to dig up

@tomleslie 

Sure, you're right.
But what I wanted was to use aliases to obtain more readable expressions and, after some transformations of thes later, "evaluate" the final expressions by substituting back the terms such as a^p (p being some strictly positive integer) by its algebraic value.


Thanks for yout answer

@acer 

I hadn't read the manual carefully enough.

Thanks for the answer

Don't you miss time derivatives ?
As it is your system is an ODE system.

@LichengZhang 

I've encountered this bug quite often. 
If youhave more complex graphs thant those you present here and if stymle=planar returns an error,  my advice is to use IsPlanar(some_graph) to verify if the graoh is planar or not.

@Kitonum 

Great, I vote up

@Preben Alsholm 

Thanks, I had forgotten to try rewritting F using Heaviside(s)

@acer 

Thanks for all these precisions (and corrections) : step by step, I keep discovering unsuspected Maple's resources.

Comparing your initial post and your procedure "Resize", I totally agree with you that using "size" directly in the tracing command is probably the simplest and most natural solution.

See you later, and congratulations again.

By the way: why do you define variables beginning with a double underscore? Is this to prevent any conflict with protected variables beginning with a single underscore?

Great, I do believe it was a necessary improvement!


The only thing it seemed possible to do so far seemed to be to reduce the size of a 3D plot, not to enlarge it.
p := plot3d(sin(x)*y^2, x=-Pi..Pi, y=-1..1):
T := Table(Column(), widthmode=percentage, width=20, Row(TextField(InlinePlot(p)))):
InsertContent(Worksheet(Group(Input( T )))):

@acer 

Excellent! Exactly what I wanted.

It works perfectly with Maple 2015 and I think I should be able to do the things work in Maple 2019.
I gave a slight modification by adding this line after  (M, P) := GenerateMatrix(%, [a, b]);
M := eval(value(M), sum=Sum);
In order to simplify Sum(1, n=1..N) into N.

Thanks again
 

@Kitonum 

Thanks.
In Maple 2015 (the version I use), the % symbol you used to "protect" an operator doesn't work. But it's not the point really, for I can use Maple 2019 at the office.
The point is more than your solution is "ad hoc" and I would have like something more "programmatic".
You will have a better idea of the underlying problem I'd like to solve if you look to my previous reply to acer.

Thank you again for your involvement

@acer 

Thanks acer.

I still haven't taken the step to buy Maple 2019: great news it works with this latter.

Bu the way (closely related to my original question): can we differentiate under the Sum or Int signs ?

This is about a course on Statistics I prepare : it is  it is intended to be based exclusively on Maple and I would like to be able do derive "in live" some basics results instead of presenting slides to which a little attention is generally payed.
Here is a sketch of what I would like to do programatically  (derivation of the normal equations used to find the coefficients of  a regression model in the least square method)

 

Download SimplifySum_bis.mw

@Carl Love 

Your method is surely correct for n large enough but I'm not sure it's still the cas for small values of n (It's more a feeling than a proof).

Another way could be to concatenate Sample(U1, floor(p*N)) with Sample(U2, N-floor(p*N)) (if p*N is an integer, or with N+1-floor(p*N) instead). Alittle bit simpler than your procedure but still suffering this "small n problem".

Where did you find RandomSampleSetup? 
Just do this :
R := Statistics:-RandomVariable(Uniform(0, 1));
exports([attributes(R)][3]);

RandomSampleSetup is in the list of the module members but I don't know where it's documented neither what it's for...

A REMARK

Your data is a collection of integer numbers: if it represents a sample of discrete random variable (which I don't know, but it's almost impossible that this sample could be drawn from a continuous random variable) it's inappropriate to plot a "histogram" with adjacents bins.
Even if this could seem more beautiful the good presentation to use in this case is a "bar plot" with vertical bars centered on the integer values.

The reason not to use adjacent bins is that it would give a completely false representation of the "sample".
In the attached file you will see a histogram of a sample drawn form a continuous random variable (for which adjacent bins makes sense) which is asymptotically the same as the one you would like to plot. Representing data through histograms, for instance, is a way to have a good understanding of these data: what would you think about a representation that would give identical plots for different data?

So, to sum up, unless you have better reasons than the beauty (which is a subjective criterion) to plot a histogram with adjacent bins, the better to do is to avoid doing it.

Histo.mw