@fff97 
So how did you write a:=a+1 (as you said) if you don't have Maple ?
More of this, if if you had written exactly a:=a+1 instead of (a=a+1) as I told you, you wouldn't have got any error.
Just before saying it doesn't work, be sure you write the things correctly.

About the file: forget it, because you don't have Maple

@fff97 
Have tou read the file in my answer ?

@m_magooda 

You write " is it that hard with only couple of power 4 terms?" 
You have 4 root for a 4th order equation (and then potentially 16 roots for a pair of 4th order llinked equations).
Look to the file above to get an idea of what the solution looks like
4th_order.mw

Now open this next file.
The command CodeTools:-Usage(...) returns the times and memory used by the operation between the parentheses
Replace A[1]: by A[1]; and obseve the solution in the elementary case of a 9x9 linear system. (m=1)

Just after there is an ettempt to solve the same problem with m=2.
Advheat-ex54.mw
I'm a patient man but I stopped the execution after waiting more than 15 minutes to get a solution ...

So just try to imagine what it is if m=4 (your radiative condition).

I don't understand what you are looking for ?
Do you want to solve a heat equation ? Numerically or symbolically ?
Do you want to build your own finite differences scheme ?
Is it of pedagological purposes: maybe you want to show the role of DeltaX and DeltaY ?

Depending on your very purpose MAPLE can (or cannot) propose you some procedures to reach it.
 

@Preben Alsholm 

You gave the answer while I was responding to Carl.
I totally agree when you write "I prefer keeping things separate"

Thanks for the clarification

@Carl Love 
I cannot see either !
The fact is that I began using pdsolve but it returned a partially explicit solution (soem intergrals where present).
The solution returned by dsolve had the form {psi__1, psi__2}, [ { psi__1, psi__2} , {psi__1, psi__2} ] (which seems odd).

Now, where does "dsolve" come from ???
In the worksheet I tried some other stuff and, at some time, I did a copy-paste of the pdsolve(...) command into a new line ... and I ommited to take the letter "p". It is as silly as that.

I realized my mistake only after having posted my answer.
I thought this strange result (why dsolve seems to work [ the first part of the solution are the same with dsolve and pdsolve ] ?) was related to the lack of initial and/or boundary conditions ?
Maybe some kind of undocummented feature ...

But very honnestly this puzzled me a lot !



 

@Ahmed111 

Hi, 

I guess the first question is: iS my interpretatoin correct (2 coupled PDEs in two unknowns psi__1(x,t) and psi__2(x,t)) ?
If it is so you need to provide initial and boundary conditions.
A priori, bur this need a closer look to the PDE system, I would say that for each n in {1, 2} :

1. psi__n(x,0) = some function of x, possibly a constant
2. psi__n(0,t) = some function of t, possibly a constant
    

More of this dsolve doesn't return a single couple of solutions.
The solution structure is {psi__1, psi__2}, { [psi__1, psi__2], [psi__1, psi__2] } : this should be avoided with correc ICs and BCs.

numelems([sol]);
                               2

whattype([sol][1]);
                              set

whattype([sol][2]);
                              list
whattype~([sol][2]);
                          [set, list]

Look now to the indeterminates of the solution(s); here I just extract the those of type "name".
The underscored quantities are "integration constants": here again they should disappear once ICs and BCs are set
indets([sol][1], name);
        {_C1, _C2, _C3, alpha, lambda, rho, t, x, _c[1]}

indets([sol][2], name);
                {_C1, alpha, lambda, rho, t, x}

Carl Love provided a solution based on his own interpretation of your question and I gave another one based on my own understanding.
I think it is up to you to determine which is the one that better fits your problem.
Once done, if you think that my interpretation suits you, you will have to choice ICs and BCs and use pdsolve (not dsolve)  to find the solution.
This is another question, the ball is in your court.

 

@Rouben Rostamian  @acer  @Mariusz Iwaniuk

The ball hits the ground for the kth time at time T(k) := k -> sqrt(2) + 2 * sqrt(2) * add(1/(2^n), n=1..k-1).

The comparison the hit times for my solution and Rouben's one (g=0 below the ground) is slightly at my advantage :-)

But the fact my solutions captures only a finite number of rebounds remains an unsolved issue  :-(

(and this whatever the values of Digits and epsilon in the test (Twall__||k - Twall__||(k-1)) > epsilon)

Here are 2 detailed plots around the 16th hit (Rouben's solution in red, min in brown))
Rouben's solution goes wrong after the 19th or 20th hit (WHY ???)

approximated value of T(16) is  4.2425543703735348354
My solution provides the value  4.2425543703735348354
Rouben's one is correct up to the 4th decimal position

@Carl Love 

Don't you think an interpretation of the question could be the one given in the attached file ?

The idea is : psi1 and psi2 are functions of x and t. Provided Fubini's conditions hold, differentiating eq1 (eq2) with respect to t and eq3 (eq4) with respect to x and substracting the results pairwise gives a couple of PDE in psi1 and psi2.

psi.mw

@weidade37211 
Your problem remains obscure for me. 
Could you give a concrete example ?


PS : I'm not even sure I could be of any help to you ... me request is simple curiosity

@vv 
Great !

@Kitonum 

Hi, 
A very interesting answer indeed !
I tried to apply it to randomly generated polynomials and I ontained "strange" results (attached file).
For instance m[0,0] sometimes appear, or monomials in only one indet, such as "y", is not represented as m[0,1].

I guess your answer fits well MarcoFerro's question , but could you generalize it to handle the test cases in the attached file ?
 

Great thanks in advance

(PS : I use Maple 2015.2)

CanYouExplainThisToMe.mw

@shaif 

PS : the problems MAPLE faces in manipulating the GBD come from the exponents (alpha-1), alpha and (b-1).
For rational exponents some tests suggest MAPLE could be capable to return the closed form (while extremely complicated, see next example) of PDF(prod, t)

pp := int( subs({alpha=1, b=1}, subs(t=u/t, p1) * p4 / t), t=0..+infinity) assuming u > 0:
pp := int( subs({alpha=3, b=1}, subs(t=u/t, p1) * p4 / t), t=0..+infinity) assuming u > 0:
pp := int( subs({alpha=3/2, b=2}, subs(t=u/t, p1) * p4 / t), t=0..+infinity) assuming u > 0:
pp := int( subs({alpha=3/8, b=4/7}, subs(t=u/t, p1) * p4 / t), t=0..+infinity) assuming u > 0:

@shaif 

First point, my previous reply contained some mistakes, with this major one
beta(1+((x-gamma)/beta)^alpha)^(k+1) 
instead of 
beta*(1+((x-gamma)/beta)^alpha)^(k+1)

apologies ...


Second point: your Burr's distribution is a generalizae one (GBD for short in the sequel).
Let me denote SBD the standard Burr's distribution 

StandardBurrPdf          := piecewise(x<0, 0, alpha*k*(x^(alpha-1) / (1+x^alpha)^(k+1)) );
StandardBurrDistribution := Distribution(PDF = unapply(StandardBurrPdf, x), Conditions=[alpha > 0, k > 0]);

Please note the piecewised definition of StandardBurrPdf.
Some trails show that MAPLE is able to compute some statistics of a SBD random variable (Mean, CDF, ...)

What about your GBD ?
Here (x-gamma)/beta has to be positive which, because of the positiveness of beta and gamma, reduces to x > gamma.
I think the correct definition of the GBD then is :
GeneralizedBurrPdf := piecewise(x<gamma, 0, alpha*k*((x-gamma)/beta)^(alpha-1) / (beta*(1+((x-gamma)/beta)^alpha)^(k+1)) );
GeneralizedBurrDistribution := Distribution(PDF = unapply(burrpdf, x), Conditions=[alpha > 0, beta > 0, gamma >= 0, k > 0]);

The problem is that MAPLE can do very little with this distribution (I hope someone here will read this and contradict me) unless we help it (see a simple example in the attached file).


Finally, with this "negative" observation, it is very unlikely for MAPLE to be able to return a closed form of PDF(prod, t)

I remain at your disposal
 

burr2.mw

@Preben Alsholm 
Thanks fot having corrected me

@Kitonum 
I use to use  sort(L, key=(x=x[1]))  instead.
Is your syntax docummented elsewhere ?