@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

@vv 

Post scriptum : I just realised that in the case of a mixture of two rvs U1 and U2 of disjoint supports it's enough to write the pdf of the mixture this way
pdf := (p,x) -> p*PDF(U__1, x) + (1-p)*PDF(U__2, x);

Of course this doesn't solve the sampling problem... but I just realised (once again) that it is very easy to sample MIXTURE(1/3) with this simple method :
U := Sample(Uniform(0, 1), 10);
map(solve, CDF(MEL(1/3), x)=~U, x); 

Now the question is: how could it be possible to declare this strategy in the definition of the Distribution (a priori by instanciating the attributes RandomSample and RandomSampleSetup) in order  to be able to invoke it while writing Sample(...., method=custom) ?