J F Ogilvie

83 Reputation

8 Badges

15 years, 86 days

MaplePrimes Activity


These are replies submitted by J F Ogilvie

@ecterrab   

192 solutions are known.  How many have been implemented in Maple?  One can not logically accept that the implementation is thorough unless all these solutions are available in Maple.

@J F Ogilvie 

Further to my preceding message, any user of Maple is grateful that Heun functions have been partially implemented, even though lacking "numerical evaluation routines".  Without those facilities for numerical evaluation, how can anybody logically consider the present implementation to be "thorough"?  Maple combines symbolic and numerical approaches and the former is of limited value without the latter.

     Other mathematical software apparently lacks these Heun functions for particular mathematical reasons, which I refrain from recalling here.  All users of Maple who have reason to solve ordinary- and partial-differential equations can admire the present resources for these purposes, which far transcend those available elsewhere, even though much more dan, and shourld be, done to implement further special functions.  When the aspect of pending numerical evaluations was mentioned some years ago, one naturally hoped and expected that that aspect would be promptly treated, but disappointing years have elapsed without that implementation, which is of interest to anybody who works with differential equations and special functiions, who far outnumber the physicists who  actually use the physics package.  Let us hope that the present appeal results in a positive response.

@ecterrab 

The fact is that only a few persons in the world use all, or even a largre fraction, of the facilities in the physics package, whereas Heun functions arise in many areas of applied mathematics and science, including physics, such as the solution of partiall-differential equations and boundary conditions mentioned above, as anybody who is acquainted with The Heun Project can confirm.

"Numerically, the only software package currently able to work with the Heun functions is MAPLE. Alternative ways for evaluations of those functions do not exist. The numerical realization in MAPLE however has some limitations which are hard to overcome considering MAPLE's closed kernel. Furthermore, outside of some specific cases, MAPLE's realization of those functions relies heavily on numerical integration, which however cannot be controlled by the user and thus it is much harder to interpret the results in the problematic areas."

The fact is that the enhancements, such as,to the numerical evaluation, were heralded several years ago, but have yet to appear.  Why the procrastination?

@dharr 

Your response to my query is most helpful.  I suspected intuitively that Dirac(x-a)2 might be simply Dirac(x-a), i.e. the function is its own square, but I can find neither justification of this idea, nor any other explanation of the square of this Dirac function (which is really a distribution rather than a proper mathematical function), which is accordingly undefined.  Any problem or application in which Dirac squared migth arise is likewise undefined. 

Your explanation is marvelous!

Although Maple has no equal for the teaching, learning and doing of mathematics during post-secondary education, I have some doubts about its introduction and application in an environment of secondary education --'high school'. I contend that it is extremely valuable -- even essential -- for pupils in school to be proficient in mental arithmetic.  There is software such as Geogebra that is designed for a school context for the essential concepts of geometry and algebra, which are far more important than calculus in that context.  With regard to quantum-chemical calculations with a Maple toolbox that might be associated with post-secondary courses of chemistry, the existence of such an amenity is valuable but only in a context of an understanding of the underlying theory.  For many purposes in a pedagogical setting, an accessibility to calculations with molecular mechanics might be preferable, because the underlying theory is based mostly on readily comprehensible concepts of physics.  There seems to be a general notion that quantum-chemical calculations are likely to be more accurate than thieir molecular-mechanics counterparts, even though the duration to achieve that accuracy might be considerable.  There is no doubt that quantum-chemical calculations at the highest level, i.e. large basis sets, configuration interaction, ... can generally yield results, after a sufficient interval, that are comparable with experimental accuracy.  The question arises whether the approximate nature of a calculation based on a reduced density matrix for two electrons, even though a quick calculation because of the approximations, will generally yield a meaningful accuracy for properties of common interest in undergraduate chemistry, namely molecular structure, electric dipolar moment, vibrational spectra, electronic transitions observable in the visible and near-ultraviolet regions and optical activity.  Not only the availability but also the efficiency of this toolbox for quantum-chemical calculations with regard to accuracy should be addressed.

This notation is desirable.  Why is it not included in Maple 2019, or perhaps it will be included in Maple 2019.1?

@ecterrab 

If a company distributes goods, the user has a legitimate right to expect the goods to work properly.  It is entirely unsatisfactory, and even unethical, for the distributor of those goods to suggest that the legitimate use of those goods would not be expected to yield the proper results.  In this case, Maple 2018 (32-bit) as distributed includes the classic interface, which still loads and exits more rapidly than the Java interface, and a legitimate user of Maple 2018 has the right to expect that that classic interface work properly.  

     Maple in the classic interface works in a standard manner without having to adjust this or that in an unintuitive manner.  I found under options the menu for preferences and chose worksheet instead of document mode, but I find nowhere a selection specified as "1D math input", so your advice is ambiguous in terms of the available options.  The first concept that one learns when beginning to learn programming of a computer is that one must be precise in one's usage, to which you have failed to conform.

     Anyhow, consistent with the spirit of your advice, I opened, and awaited, the 'standard' interface, selected worksheet mode and then "Maple notation" -- is that what you meant? -- for input notation, and accepted "apply globally".  At the command prompt I entered only a formula with a name; this is what appeared.

------------------------------------------------------------------------------------------------------------------------------------------------------

y := x^2*sin(x)*exp(-x^2);
Warning, this version of the "Physics Updates" is intended for

   Maple release  2018.2 , while you are using  Maple 2018.0

  . Please check at http://www.maplesoft.com/products/maple/feat\

  ures/physicsresearch.aspx for the availability of a version

   of the "Physics Updates" for the copy of Maple you are using.
                          2           /  2\
                    y := x  sin(x) exp\-x /

------------------------------------------------------------------------------------------------------------------------------------------------

How do you explain that warning?  What does entering a simple formula in the worksheet mode have to do with the "physics updates"?

Incidentally, I await impatiently the long promised improvements of execution of Heun functions.

 

 

 

 

Does Maple 2018.2 require Maple 2018.1 to be installed and operating before Maple 2018.2 can be installed?  There were severe problems with the classic interface with Maple 2018.1 in that text lines were poorly incorporated.  I should not wish to install Maple 2018.2 unless that problem has been solved.  If Maple 2018.2 does not require Maple 2018.1, I am prepared to undertake the update.

The most valuable improvement or extension for my applications would be the enhancement of the special functions, to include Lame functions for instance; in particular, we have read that greatly improved mechanisms of computing Heun functions are imminent, so 2019 would seem to be viable for their implementation.  I found one example of a numerical integration of a product of two HeunC functions that simply refused to yield a result -- a purely numerical integration!!!  Why, after all these years, does Maple not include all the special functions in Abramowitz and Stegun, let alone the NIST Handbook?

In presenting a solution of a differential equation, Maple generally chooses the most general special function, e.g. Whittaker even though Laguerre functions are better known and supported.  The Help files for these special functions present only some possibilities for simplification or conversion to other forms; for instance for the Heun functions, 192 special cases are known, some of which include functions unavailable in Maple 2018, but far fewer cases are listed in the Help file.

A greatly enhanced capability of solution of integral equations is long overdue; the present methods work with only linear equations and even not all those that might have algebraic solutions.  The present status of integral equations is in sharp contrast to the status of differential equations, in which Maple is supreme.

 

Users of Maple are keen to have improved capability of working with Heun functions, and functions that are special cases of Heun functions, such as Lame functions.  There has been little or no advance with these functions for a few years, despite the opportunities for their extension and improvement.  When can we expect to see the promised results acquired from experience with the Appel functions?

@Preben Alsholm 

The stated assignment is in fact a formula involving quantum numbers for the hydrogen atom that arise in a particular system of coordinates in which Schroedinger's equation is solvable on separating the spatial variables.  The use of n, n[1] and n[2] follows traditional notation ever since Schroedinger's third paper in the important series in 1926.  When that assignment fails in Maple, for no good reason, then one reluctantly joins those "in the know" who must abdicate the logic of the traditional notation to abide by a programmer's imposition in the design of Maple.

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.

1 2 3 4 5 Page 1 of 5