J F Ogilvie

263 Reputation

11 Badges

20 years, 24 days

MaplePrimes Activity


These are replies submitted by J F Ogilvie

@tomleslie 

I do not mind that somebody altered the specifications on forall -- and yes, I read the Help page on forall and exists in Maple 2020 -- what I seek is an alternative mechanism to accomplish the same objective.  Here follows a list of these forall and define statements. Maple 2020 does not object to rule 7 that conforms to the present specification, but I have no idea how to modify the other rules to achieve the same result.  Your assistance will be greatly appreciated.

> # Rule 0: Operate on existing D
> rule0 := forall(Dtest(x), TD(x) = D(x)):
> # Rule 1: The basic operation
> rule1 := forall(function(x), TD(x) = ''convert(map((t,X) ->Diff_function(X,t)*D(t),[op(x)],x),`+`)''):
> # Rule 2: Chain rule for products
> rule2 := forall(TD_plus(x), TD(x) = ''TD(op(1,x))
>          *convert([op(2..nops(x),x)],`*`)'' + ''TD(convert([op(2..nops(x),x)],`*`)) *op(1,x)''):
> # Rule 3: Handle strings and numbers
> rule3 := forall(string(y), TD(y) = D(y)):
> rule3a := forall(numeric(y), TD(y) = 0):
> # Rule 4: Deal with sums
> rule4 := forall(TD_mult(x), TD(x) = ''convert(map(TD,[op(x)]),`+`)''):
> # Rule 5: Deal with Diff and diff
> rule5 := forall(Difftest(x),TD(x) = ''convert(map((t,X) ->Diff(X,t)*D(t),indets(indets(x,`Difftest`),algfun),
>          x),`+`)''):
> rule5a := forall(difftest(x),TD(x) = ''convert(map((t,X) ->diff(X,t)*D(t),indets(indets(x,`difftest`),algfun
>           ),x),`+`)''):
> # Rule 6: Make sure TD works with equations
> rule6 := forall(`=`(x), TD(x) = ''map''(TD,x)):
> # Rule 7: and powers
> rule7 := forall([x,y], TD(x^y) = y*x^(y-1)*TD(x)):
> # Rule 8: Above all, be able to handle indexed variables when applying TD.
> index_proc := proc(a)
> local t;
> if op(0,op(0,a)) = `Diff` then # is head Diff ?
>   TD(op(0,a)); # yes
>   t := map((x,y)->map((x,y) -> x[y],x,y),TD(op(0,a)),op(a)); # diff wrt vars
>   subs(map(x -> x = D(op(op(0,x))), select(has,indets(t),`D`)),t); # deal with indeces
> elif op(0,op(0,a)) <> string then
>   subs(op(0,op(0,a)) = op(0,op(0,a))[op(a)],TD(op(0,a)))
> else
>   subs(op(0,a) = op(0,a)[op(a)],TD(op(0,a)))
> end if
> end proc:
> rule8 := forall(indexed(a), TD(a) = ''index_proc(a)''):
> # The TD operator is created with the define command.
> TD := 'TD':
> define(TD,rule8,rule7,rule6,rule5,rule5a,rule4,rule3,rule3a,rule2,rule1,rule0):

 

.

@tomleslie 

Several such 'forall' statements were entered into a valuable worksheet in Maple 4.3 by 'Steve Adams' who was at that time, 1993, an employee of Maplesoft.  Each statement was of the form

 > rule1 := forall(function(x), TD(x) = D(x));

and the several rules were collected into a define command.

> TD := 'TD';   >  define(TD, rule9, rule8, ....., rule1, rule0);

Such programming based on rules is common in Reduce and Mathematica, but this instance is the first of my acquaintance in Maple.  I should be grateful for a mechanism to effect such rules.

 

@ecterrab 

For the few theoretical physicists in the world who can benefit from developments in particle physics, general relativity, Feynman diagrams ..., Maple 2020 is a great advance.  There are thousands of Maple users who also appreciate the capabilities of Maple to solve ordinary- and partial-differential equations, and there is some advance here in Maple 2020 also,for linear differential equations with hypergeometric functions in the solution, but there is so much more that could be done in this area including the associated special functions for which development in recent years has been lagging.  Not only physicists,but also applied mathematicians, chemists and engineers of many branches -- in their thousands -- would be grateful for such developments as further special functions, such as Lame functions, and improved calculations with present functions, such as Heun functions of all sorts,  There are 192 solutions to Heun's differential equation:  how many of those solutions can Maple find?  The Help page is unclear about this matter.  A worthy objective for Maple 2021 would be to complete all the lacking functions present in Abramowitz and Stegun, with a comparable objective for the NIST Handbook for Maple 2022.

@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.

1 2 3 4 5 6 7 Page 3 of 7