When I entered this logically correct assignment in Maple 2017.3 (classic interface)

    n := n[1] + n[2] + abs(m) + 1;

the system responds

    Error, recursive assignment

for exactly the reason that Dr. Lopez has stated.  In that same interface, input of

   n := n__1 + n__2 + abs(m) + 1;

generates output of

     n := n__1 + n__2 + |m |+ 1

rather than the intended subscripted variables n1 and n2.

It is welcome news that somebody, hopefully at Maplesoft, is aware of this anomaly shown in the error message above and will take measures to resolve this dilemma.  The enduring presumption that each subscripted variable must imply a table has been a chronic annoyance to users of Maple, whereas mathematicians and physicists legitimately apply subscripted variables in their notation and calculations, simply because there are too few letters in the alphabet, even latin and greek alphabets combined, to encompass all practical possibilities for compact and concise symbols.

>Scheq := 1/2*h^2/Pi^2/mu*(diff(psi(xi,eta,phi),`$`(xi,2))*eta^2*xi^4-diff(psi(xi,eta,phi),`$`(eta,2))*eta^4*xi^2+2*diff(psi(xi,eta,phi),xi)*eta^2*xi^3-2*diff(psi(xi,eta,phi),eta)*eta^3*xi^2-2*diff(psi(xi,eta,phi),`$`(xi,2))*eta^2*xi^2-diff(psi(xi,eta,phi),`$`(xi,2))*xi^4+diff(psi(xi,eta,phi),`$`(eta,2))*eta^4+2*diff(psi(xi,eta,phi),`$`(eta,2))*eta^2*xi^2-2*diff(psi(xi,eta,phi),xi)*eta^2*xi-2*diff(psi(xi,eta,phi),xi)*xi^3+2*diff(psi(xi,eta,phi),eta)*eta^3+2*diff(psi(xi,eta,phi),eta)*eta*xi^2+diff(psi(xi,eta,phi),`$`(xi,2))*eta^2+2*diff(psi(xi,eta,phi),`$`(xi,2))*xi^2-2*diff(psi(xi,eta,phi),`$`(eta,2))*eta^2-diff(psi(xi,eta,phi),`$`(eta,2))*xi^2+diff(psi(xi,eta,phi),`$`(phi,2))*eta^2-diff(psi(xi,eta,phi),`$`(phi,2))*xi^2+2*diff(psi(xi,eta,phi),xi)*xi-2*diff(psi(xi,eta,phi),eta)*eta-diff(psi(xi,eta,phi),`$`(xi,2))+diff(psi(xi,eta,phi),`$`(eta,2)))/(eta^4*xi^2-eta^2*xi^4-eta^4+xi^4+eta^2-xi^2)/d^2-1/2*Z*e^2/Pi/epsilon[0]*psi(xi,eta,phi)/d/(eta+xi) = E*psi(xi,eta,phi);

Applying pdsolve to the above partial-differential equation yields three ordinary-differential equations, of which two are coupled, as follows.
> Xieq := diff(Xi(xi),`$`(xi,3)) = (-4*(xi-1)^2*((-1/4*xi^2+1/4)*diff(Xi(xi),xi)+Xi(xi)*xi)*h^2*(xi+1)^2*epsilon[0]*diff(Xi(xi),`$`(xi,2))+2*h^2*xi*epsilon[0]*(xi-1)^2*(xi+1)^2*diff(Xi(xi),xi)^2-2*Xi(xi)*h^2*epsilon[0]*(xi-1)^2*(xi+1)^2*diff(Xi(xi),xi)-4*Xi(xi)^2*(E*Pi^2*d^2*mu*xi^5*epsilon[0]+1/4*Pi*Z*d*e^2*mu*xi^4-2*E*Pi^2*d^2*mu*xi^3*epsilon[0]-1/2*Pi*Z*d*e^2*mu*xi^2+epsilon[0]*(1/2*m^2*h^2+E*Pi^2*d^2*mu)*xi+1/4*Pi*Z*d*e^2*mu))/h^2/Xi(xi)/epsilon[0]/(xi-1)^3/(xi+1)^3;
> Etaeq := diff(Eta(eta),`$`(eta,2)) = (h^2*Eta(eta)*epsilon[0]*(xi-1)^2*(xi+1)^2*(eta-1)*(eta+1)*diff(Xi(xi),`$`(xi,2))-2*h^2*Xi(xi)*eta*epsilon[0]*(xi-1)*(xi+1)*(eta-1)*(eta+1)*diff(Eta(eta),eta)-2*(-h^2*xi*epsilon[0]*(xi-1)*(xi+1)*(eta-1)*(eta+1)*diff(Xi(xi),xi)+((eta+xi)*(E*Pi^2*d^2*mu*(eta-1)*(eta+1)*xi^2-eta^2*E*Pi^2*mu*d^2+E*Pi^2*d^2*mu+1/2*m^2*h^2)*epsilon[0]+1/2*Pi*Z*d*e^2*mu*(xi-1)*(xi+1)*(eta-1)*(eta+1))*(eta-xi)*Xi(xi))*Eta(eta))/h^2/Xi(xi)/epsilon[0]/(xi-1)/(xi+1)/(eta-1)^2/(eta+1)^2;
> sol2 := dsolve({Etaeq,Xieq}, {Eta(eta),Xi(xi)});
>

With Maple 17 and before, this system of ordinary-differential equations that results from a partial-differential equation was solved with both 32- and 64-bit versions of Maple, but since then the 32-bit version produces either, after a few minutes, a hopelessly long and incorrect answer or  just " {  } ", whereas the 64-bit version produces a simple and presumably correct answer in a few seconds.  This disparity should NEVER happen, but it continues to happen despite being notified to Maplesoft.  How can we have confidence in further developments of partial-differential equations in Maple if this problem recurs and recurs and recurs in new release after new release after new release?

Of course one would wish that the number of special functions would increase and that the information about them provided by the function advisor would correspondingly increase, to include Lame and spheroidal wave functions for instance.  With the existing Heun functions and the new Appell functions, which are astonishingly absent (!) from the list of functions under Function Advisor (basic) above, there might be a risk of excessive complication in a solution of a differential equation.  For instance, Maple 2017 produces the solution of Schroedinger's equation for the canonical quadratic linear harmonic oscillator in terms of WhittakerM and WhittakerW functions in a sum -- as two independent solutions appropriate to a differential equation of second order, although the solution in textbooks is almost invariably proffered in terms of a product of an exponential function and Hermite polynomials.  The WhittakerM functions fail the boundary conditions, leaving the WhittakerW functions as a single solution.  The 'help' pages mention the problem of proferring a representation in terms of 'simpler' [than what?] functions.  Why does Maple 2017 not provide a general mechanism to yield solutions in terms of simple functions so that those Hermite functions would appear directly as at least one independent solution, with the corresponding other independent solution?   The Heun functions and apparently the new Appell functions are so general that they include many other functions as special cases, but a user would almost invariably prefer the special case as involving decreased complication in succeeding manipulations.

The 'adjusted r²' parameter is an improvement on r² itself, but the adjustment seems to have been done in a purely empirical manner.  My authority on statistics or regression informed me about another parameter that has a perhaps superior theoretical basis.  Akaike's criterion of information is suitable for not only linear regression involving single or multiple independent variables (regressors) but also non-linear regression.  Its proper correction to take into account a number of data sets in a sample as

                                 AIC = ln(SSE)  +  2 p / n

in which SSE denotes the sum of squared errors (residuals); parameters number p and observations number n.  The smaller or more negative is the calculated value of AIC, the better is the fit.  My book Mathematics for Chemistry with Symbolic Computation, available gratis from the Maple Application Centre, discusses and applies this criterion in chapter 8. 

It should be abundantly clear to another reader that Dr. Cheb-Terrab's expansive replies have provided to me no information that is either relevant or not already known to me.  His time and effort might better be devoted to the development of differential equations and special functions, now that the general relativity package and other esoteric parts of the physics package are in such excellent condition. 

For instance, why is it that the solution of two coupled ordinary-differential equations, after Maple 17, takes forever to produce a useless long expression in the 32-bit version of Maple but the correct and compact answers rapidly in HeunC functions in 64-bit Maple? Such anomalies depending on the version of Maple in one and the same release should never happen, and that condition is not something that a user of Maple can remedy.

As a second instance, under FunctionAdvisor(specialize, HeunC(a,b,b,c,d,z/2+1/2)); the output is alleged to yield one of four (new) AppellFn functions, n=1..4, according to the same condition "And(a=0,1+b<>0,c=0,z/2+1/2<>1)" in each and every case.  Is there a lottery mechanism inside Maple that decides which AppellFn function should be appropriate in a particular application?

I ask again:  how many of the 192 solutions of Heun's equation are incorporated in Maple?  Maple 2017 and its developers can take pride in, supposedly, providing about 900 solutions of Einstein's equations.  I seem to recall that Maple was, several years ago, the first general mathematical program to provide any Heun functions at all, but progress in expanding the coverage has been slow because the attention has been devoted elsewhere. Might we expect Maple 2018 to incorporate all those 192 solutions of Heun's equation, including all special cases such as might occur in terms of Lame and spheroidal wave functions? In real applications of Heun functions in problems across science and engineering, the simple conditions such as appear in the "And(..." above -- a=0 or1/2 or 1 ... -- plainly do not apply, in which case Maple seems to leave the user 'high and dry', with no practical path forward to solve the pertinent problem.  We look to the developers of Maple to enable the user to focus on the results of the calculations, "while leaving the algebraic difficulty to the computer".

I absolutely agree that Maple is 'not any more “just a computational research aid” but a "true learning environment"'. In fact, my book Mathematics for Chemistry with Symbolic Computation, based on Maple worksheets, has recently been announced, in its fifth edition, to be available gratis from the Maple Application Centre. Indeed "One can concentrate on learning and working with the concepts at the same time, while leaving the algebraic difficulty to the computer", consistent with Lord Kelvin's statement "The human mind is never performing its highest function when it is doing the work of a calculating machine."  A colleague and I have just prepared a paper for an online conference on mathematics in chemical education in which we extoll the power to solve mathematical problems that students enrolled in our courses based on the specified textbook have acquired, such that several of them have submitted contributions to the Maple Application Centre; in four instances these contributions were known to the instructors only after they appeared in the announcements of that Centre, so they were completely spontaneously generated, based on that power, and submitted, entirely independently of the instructors. 

About the Heun functions, are all 192 known solutions of the Heun equation embodied in Maple 2017?  Are all transformations of these various Heun functions embodied in Maple?  The answer to these questions would seem to be "NO" because Lame functions that are lacking in Maple are an important special case of Heun functions.  The lack of these, and spheroidal wave functions, is impediing the development of the quantum mechanics (wave mechanics) of the hydrogen atom, which is just as important in chemistry as it is in physics, in both cases in a "true learning environment".

The use of statistics as a defence of the status quo is certainly a sign of desparation.  How many of those 2.5 million seekers of information about general relativity are ever likely to use that admirable functionality in Maple?  Compare that minute fraction with a major fraction of seekers of information about Lame functions that might use the functionality of Lame solutions in Maple if it existed.  That is a more honest appraisal of the relative merits.  The entire gist of my comments and criticism is that we want more and better convertible special functions, and improved solution of differential equations, in Maple, for applications across science and engineering, not just those required in the numerous solutions of Einstein's equations in esoteric general relativity.

I repeat what I wrote in the first comment on this announcement.

As much as one can admire the great achievement regarding calculations in general relativity in Maple 2017, there is much more than general relativity in physics.  Even only a small fraction of physicists will ever use this functionality despite its scope and power.

In no way can this compliment be considered disrespectful.  The reply to that comment was simply a repetition of what we, who eagerly await further special functions and advances in the solution of diffferential equations, have already read on more than one occasion. Yes, the FunctionAdvisor is commendable and the conversion network is valuable, but, despite no lack of material for inclusion in successive releases of Maple, there has been little development in the past two or three years.  The Appell functions that are included in Maple 2017 are so obscure that Abramowitz and Stegun did not include them in their Handbook, although the successor NIST Handbook does incorporate them, like many other functions that are lacking in Maple.  To a user of mathematical software across science and engineering who relishes expanded capability in special functions and the solution of differential equations, the package for general relativity, like the new package for geography, is indeed an irrelevant distraction.  Maple has contained Heun functions, which are also not in Abramowitz and Stegun, but, several years afterward, not yet the related Lame and spheroidal wave functions.  Much more can, and should, be done to make these functions, and their conversions, easier to use.

Yes, a few Appell functions are included in Maple 2017.  In my abysmal ignorance, I had never heard of these obscure functions, but perhaps I might be excused because neither had Abramowitz and Stegun in their 1046 pages of Handbook of Mathematical Functions that contain many, many useful functions that are lacking in Maple.  I consulted a professor of physics, in the vicinity, who is a specialist in general relativity, who mentioned that those numerous solutions of Einstein's equations might be useful to some other specialist physicists in general relativity, but that he had no personal interest in, or use for, them, whereas certainly many other scientists and engineers in the vicinity have interest in, and use for, special functions that are lacking in Maple.  A few years ago I advocated the objective to include all functions in Abramowitz and Stegun in Maple, such as occur in the solution of differential equations important in scientific and engineering applications, but progress in this direction is slow because of irrelevant distractions.

As much as one can admire the great achievement regarding calculations in general relativity in Maple 2017, there is much more than general relativity in physics.  Even only a small fraction of physicists will ever use this functionality despite its scope and power.  Meanwhile, whilst all the attention has been devoted to general relativity, other aspects of physics and more general mathematical applications have been neglected.  For instance, what has happened to the long urged inclusion of all of Abramowitz and Stegun into Maple, let alone the NIST Handbook?  Many of those special functions have been incorporated, but others are lacking, such as Lame functions, and still others are incompletely installed, with poor or no transformations to included functions that run at better than a snail's pace.  The Heun functions were included in Maple some years ago, but there is much still to be done to make those functions work efficiently.  Many special functions have applications well beyond the limited bounds of physics, such as in chemistry, engineering ...  It is about time for the train of development of general relativity to be placed on a siding to allow other aspects of physics, differential equations and mathematical functions to be given a fair ride forward.  Particle physics is a long way from the reality of science in which most users of Maple operate.

I agree absolutely with the sentiment expressed by vv1314.  What is the fraction of special functions in Abramowitz and Stegun that is incorporated in Maple?  Certainly some important special functions are lacking, such as spheroidal functions and Lame functions.  Implementing each additional special function is undoubtedly a significant task as it involves enabling transformations and conversions with all pertinent previouslly existing special functions.  Please report to us what is that fraction.

The semantics of this title are somewhat unclear, but what is absolutely clear is the capability of advanced mathematical software such as Maple to contain mathematical knowledge accumulated over five thousand years of human history -- not merely to contain that knowledge as in a printed book in a 'fossil' form but to enable a user directly to discover and to apply that knowledge in a live and interactive computational environment. 

Edgardo Cheb-Terrab has, of course, been a prime mover in implementing within Maple not only the exact solutions to Einstein's equatiions, which are of interest to, and application by, only a tiny fractiion of users of Maple, but also many, but not all, manthematical functions collected by Abramowitz and Stegun or in the NIST Handbook of Mathematical Functions. which arise in the solution of differential equations that are a strong feature of Maple and of much more general interest and applicability.

We can hope to expect to read in imminent releases of Maple further developments of mathematical functions and their applicability in the solution of differential equations.

For the first time I have noticed use of ~ before a symbol in input; in output I understand that to imply a quantity subject to some assumption.  What does it mean in input?  My attempt to use Maple Help for this purpose failed.

@ecterrab I am delighted to read this information; it seems unfortunate that this achievement could not have been incorporated within Maple 2016 as released, because Maple 2016 was installed in our computers in CECM only some days ago, but naturally everything cannot be done simultaneously.

Yes, Edgardo Cheb-Terrab exerted a massive effort to achieve the objective of incorporating all solutions of Einstein's field equations, and has made Maple superlative in this narrow area of theoretical physics.  We hope that he can achieve another completeness by incorporating all mathematical functions in the NIST Handbook, or at least those in Abramowitz and Stegun from 1962.  The missing functions, such as spheroidal functions, are of immense value not only in a particular segment of theoretical physics but also broad areas of mathematics and even chemistry.  Maple is the only mathematical software to include Heun functions, but there is much that can be prospectively done to make those functions more amenable to applications.  Maple 2016 is a worthy successor to preceding releases, but much remains to be incorporated to reflect 5000 years of mathematical knowledge.  Might we hope that a simiilar completeness will be boasted in Maple 2017?

To extend the worhy and illuminating post of Samir Khan a little, I should have wished that the spreadsheet built into Maple were a little easier to use, and especially that it might offer larger dimensions than 100 x 52 cells.  I hope that Samir's interest at this time might indicate that Maple 2016 might have expanded functionality in this facility. 

     Incidentally, on the most recent occasion on which I used the Maple spreadsheet, a couple of years ago, I found that some facility that worked properly, i.e. as announced, in preceding releases of Maple failed to work in that one.  It is really disappointing and frustrating to a perennial Maple user and supporter to discover such occurrences, which arise through tampering with code for some presumably significant reason and then failing to test whether the associated commands still work properly.