Hi

It would helpful if you could formulate your problem, that is: show the input and what you'd expect as the output of an ideal command you are looking for. Beforehand I can say what you are looking for is not already present in Maple as a command (unless you can formulate your problem in terms of Lie algebras, in which case perhaps in the DifferentialGeometry package ...) but if it is not present it is definitely doable. Within the Physics package you do have the tools for working with noncommutative objects, satisfying any commutation rule you want, including in that commutators and anticommutators - these are part of the package - and algebraic representations for differential operators - this is highly unusual in computer algebra systems and implemented in the latest versions of Physics; these frequently help in explicitly representing operators satisfying different types of algebra rules.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

@Adam Ledger 

Many of these things we do not understand involve some convention that we are simply not aware of. This kind of situation is perfectly OK, not embarrasing. If the subject is relevant, with time one has the opportunity to get more and more familiar with these subtleties.

Another one of this sort is that in hypergeom([a, b], [b], z) you cannot automatically cancel the pochhammer of the numerator and denominator related to the parameter b (ie you cannot make hypergeom([a, b], [b], z) equal to hypergeom([a], [], z)) until you are sure that b is not a negative integer or zero (b::nonposint), because in that case the hypergeom function is a polynomial, ie the series is conventionally truncated right before both pochhamer functions, in the numerator (first list) and denominator (second list) evaluate to 0 as the summation index - say n - is equal to abs(b) + 1. The problem being that, If in this case you make the transformation hypergeom([a, b], [b], z) -> hypergeom([a], [], z), you miss the information that the function is polynomial, and get a wrong result.

Here again, without familiarity, I'd think that the hypergeom([a, b], [b], z) is undefined when b::nonposint because you have something of the form 0/0, when the summation index n is equal to abs(b) + 1. But the series is one thing, the function is another, and the series can be "analytically extended" to become the function including this case b::nonposint by truncating the series at n = b, so right before the pochhammers in numerator and denominator become equal to 0. Clearly all this in conventional.

Sometimes we forget about this distinction between actual mathematics and the conventions to make it work. There is nothing embarrasing with not being famliar with the mathematics and much less with not being familiiar or aware of the conventions.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Funcctions, Maplesoft

@vv, _Maxim_ 95

Generally speaking:

• Inert objects are not assigned. Example: %MeijerG has no procedure or anything else assigned to it (BTW what do you mean by "%MeijerG() does not appear to be very inert"?)
• Relevant parts (however not all, progressively more) of the library know about inert objects, a concept introduced in Maple not long ago. Originally (1990?) there was only Diff, Limit, Product, Sum, Int. Nowadays %everything is the inert representation of everything you could think of, and value(%foo) -> foo. Even value(%A[j]) -> A[j]. When these inert %everything were introduced into the library, all of diff, expand, series, evalf, and other kernel commands were taught about them. Nowadays more and more commands of the library - not just those kernel builtin unreadable ones - know about them.
• Regarding mathematical functions, their normalization is programmed in the function, and the simplifier, generally speaking, does not have normalizations programmed (understandable) nor applies them systematically to inert functions (debatable; the obstacle here is that not all the functions have their normalization detached from the core code, accessible without transforming the inert into full active).

By "generally speaking" I mean both that there are exceptions to these items, e.g. %assuming has a program attached or otherwise it simply could not accomplish its task, that is to represent an assuming call inertized, or also in some places the simplifier does apply a normalization for reasons A and B, that are not the point here; and I also mean work in progress: more modern code (e.g. the Physics package) is programmed taking inert objects into account basically all around. On the other hand, the simplifier, older code programmed before the introduction of this general inert concept, has many ramifications (trees of subroutines) not all of them taking inert objects into account, or not all around. I am not surprised with what you show, vv. I coded the main extension of simplify to handle inert objects in 2008 (for those understanding Maple code, the routine is visible, called `simplify/inert`). Then I coded the typesetting of inert everything only for Maple 2016, when extended typesetting became more mature.

All in all, I think inert everything is a tremendous^2 feature in a computer algebra system. The implementation as of today is not as complete as I would like, but then other things are also not complete, that is how evolution works, but the amount of things you can already do with inert everything is huge and astonishing, and more at every release.

PS: on the original topic of this thread, this issue in the normalization of MeijerG needs to be addressed; I will reserve time this week for that.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

So, as if I were only an enthusiastic Maple user: generally speaking, I liked this post and I like the idea. In fact, something similar is what I implemented as a Maplesoft designer/programmer with the Maplesoft R&D Physics, Differential Equations and Mathematical Functions webpage.

So let me first clarify that: It is not just about Physics, but also about all the DE and Mathematical Functions code. All that gets patched for everybody in that official Maplesoft webpage and these patches are in fact the ones that get into the Maple library under development at the same time (albeit, subject to further revision as the development cycle evolves - these revisions are also made available on the same webpage). These patches are sometimes noticed here because of posts, as it happened recently in connection with pdsolve, but in fact there are many per week, and frequently there are many per day: it is not just about patches (my tolerance to actual bugs is as close to 0 Kelvin as the uncertainty principle permits ...), but also new developments.

OK. Can some of this be generalized to previous versions and include the work of everybody? (Somehow, that seems to be the idea.) I think this is partly possible if you allow for some levels of imperfection. I personally have no problems with that - there is always some. However, let me bring some pro-experience: patching for previous releases, is rather^2 complicated: unless the fix is very specific, it is very easy to have undesired side effects, as to make some other things not work anymore as expected. You'd be surprised with how much of this happens every day during development. Code is only valuable if it has a TON of tests behind, and even then it is impossible to test it 100%, because it depends on other code, that depends on other code, that ... etc. An enormous amount of tests are run before introducing a small change in the Maple library, and sometimes there is more time spent in testing than in actually producing a fix.

On the other hand, patching the current version of Maple is simpler. I am not trying to sell here. It is simpler because the company always gives a look at users suggestions of patches when it is the current version, and then some form of informal collaboration is frequently possible, with benefits for everybody. The author can contribute the patch to a patch library not maintained by the company, that can be organized by Maple users as Christopher2222 suggests, and made available to others in the Maple Cloud and, by exchanging emails, as said even if informally, the patch can maybe, eventually, get tested against the Maplesoft test suite for real, +/- some professional tweaks as Preben suggests. Testing against the immediate previous release is also not impossible, but tweaks for a previous release by Maplesoft people is unrealistic ... we are so involved with the current release that there is basically not time for anything else.

In summary, it seems to me this is a nice collaborative idea, requiring just some refinements if it is going to happen for real; mainly I'd suggest you patch for the current release first.

Edgardo (not as Maplesoft).

This is a bug. I will see that it gets fixed today and upload the fix to the Maplesoft R&D Physics, Differential Equations and Mathematical Functions webpage; will write here again when it is ready.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

@tomleslie 

What is not rocket science is to describe how Maple's dsolve works regarding integration constants, and that is what you describe. What is also not rocket science, however not convincing to me is to say that there "may be a bug" as in "this or that command may be reusing constants the wrong way" without showing one single example of any sort after perhaps 15 replies. Anyway, I need to move forward to other tasks, leaving this conversation for now.

Best

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

@John Fredsted 

Hi, just to say that I am pretty easy to convince, but you need to show an example. In this whole thread with so many replies, however, I've seen not one! I'm also aware that bugs exist in software, of course, but again: you need to show one example of it at least. Without that example, the claim that "there may be a bug" is empty (no offense meant please).

Best

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

 @tomleslie 

What you show is the opposite of what was mentioned. I.e.: PDEtools:-Solve is not reusing an integration constant such that the solution is wrong or incomplete. 

As for the idea conveyed by your post, this is it: the integration constant of a 1st order ODE is _C1 (unless someone assigned it, or unless it was found itself in the given ODE). So if you send an 1st order ODE one at a time, the integration contant is always _C1. I was this way in 1996 when I wrote a new (the current) dsolve, and because I find this the correct design I kept this in place. The _C1 is an arbitrary constant. It can have any value in the first solution returned. It can have any other value in another solution returned some lines after.

Now if you send two of them in one go as a system of equations, think a bit, would it be correct to return _C1 for both? No. Why? Because, within a single solution, it does imply that the value of _C1 is arbitrary in itself but the same in both parts of the single solution, and thus it would be "a particular case" (when the two integration constants are equal to each other), not the actual general solution case (when the two integration constants are different).

As for the consistency issue mentioned by Preben, I have two comments. First, we know that mathematical software keeps evolving, some design decisions made day 1 are not ideal day 10. We keep them in place nevertheless, mainly to not complicate the life of people who got used to that design and have work based on it. But there is another thing here:_C1 is completely arbitrary. Change it by 1/_C1 and the solution is still a solution. Changed by f(a,b,c) (not depending on the independent variable of the ODE) and the solution is still a correct solution. On the other hand, _Zn is not as arbitrary. Change it by _Zn / 2 and the solution returned by solve is not a solution anymore. Although I can see how annoying is to receive a different _Zn each time you call solve (even with the same equation!), the situation is not entirely the same as that of the integration constants _Cn returned by dsolve.

Having said that, for instance in the pdsolve & BC new code (check it out in Maple 2017.2), the summation dummy is not anymore of the form _Zn (with each time a different _Zn released by solve) but now uniformily equal to 'n', or 'k' if n is itself found in the PDE, or another letter if also 'k' is there. In fact it is not difficult to tweak PDEtools:-Solve to return the same _Zn at least when the same equation is entered... (at the cost of having PDEtools:-Solve not returning exactly as solve, that each time releases a new _Zn).

Anyway, just to say that if you Jonh think that Tom Leslie summarized your problem, then my opinon here is that there is not a problem, really. Having dsolve releasing a different _C1 each time a 1st order ODE is passed would only complicate life, and no there is no any "erroneous reuse of integration constants" by PDEtools:-Solve, at all.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

@John Fredsted 

To reproduce a problem as the one you describe, I may be sufficient to post a worksheet containing, only, the two differential equation systems.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

@John Fredsted 

g_[~mu,nu] is used in physics all the time, in textbooks, papers and calculations by hand. Enforcing it to be displayed as KroneckerDelta would be artificial, for me at least. The same about KroneckerDelta[a, b] or [mu,nu], I see it as such here and there. Then you raise and lower indices in KD the same way, contracting with the metric. And the components are also well defined, as shown above for the (1,1), (2,0) and (0,2), nothing illegal.

Anyway just to say that I prefer things the way they are. People actually working with the package also use both kd_ and g_ normally, with both input and output as expected, all ok, but for the help page I mentioned - that needs a rewriting. 

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

@nm 

It is all about the method used. Try userinfos and you will see:

@Rouben Rostamian  

Yes, that is another way to put it. Check the documentation, it is mentioned there in ?dsolve,details, reversing expressions involving fractional powers have these problems, we can tell "in advance" that what you will get doing that is not correct all around. The behaviour observed is intentional. Programmed to be that way.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft.

@J F Ogilvie 

I still think that special functions is not the topic of this post, but you want to comment on them and on different aspects of Maple development anyway; ok. My comments are that some of the things you say could start a separate valuable blog/exchange, but some other ones you say look to me not accurate.

First, topics not related to this post but that I find interesting, worth an exchange of ideas.

• All computer algebra system (CAS) nowadays have very advanced mathematics/physics functionality.

Why? Because modern CAS are not anymore “just a computational research aid” but became "true learning environments". Within a CAS worksheet, difficult stuff is - just - easy, fun for real. One can concentrate on learning and working with the concepts at the same time, while leaving the algebraic difficulty to the computer. For me, bringing otherwise difficult and advanced stuff to the tip of my fingers not only is exciting but changes the research and learning game entirely. Some good examples of this are: 

1. The FuntionAdvisor brought a myriad of special functions so close to everybody that we all now feel like special function experts :)
2. The symmetry methods implemented in PDEtools and DEtools also brought the Lie symmetry theory unbelievably close to everybody. I truly think Lie methods are nowadays so much more understood by many, just because of this fully detailed CAS implementation.
3. The tensor and general relativity routines of the Physics package, that you mention, also brought this otherwise very difficult area close to everybody who is curious about it, not just physics students. This Maple package indeed allows for studying general relativity with incredible ease, e.g. following any textbook reading and reproducing results on a Maple worksheet, with all the heavy algebra performed by the computer. I recall that general relativity was one of the first motivations people had to write the first computer algebra systems (e.g REDUCE).
4. Special functions are one more example of the same: CAS are making them surprisingly accessible. So, It took only a few CAS years to make Gauss 2F1 (mentioned in Abramowitz and Stegun (A&S)) be trivially generalized to the pFq hypergeometric function (not mentioned in A&S), or the Heun functions be a solid part of the mathematical language (to a point where they are now mentioned in NIST), and now the doubly hypergeometric functions called AppellF from 1 to 4 (these are also part of the NIST and in Maple we implemented not just a few, as you say, but all the Appell functions, there are no more than 4). Appell functions are popping up in the literature more and more by the day. Check also in Google and you will be surprised to discover that during 2016 the number of hits for Appell functions is approx 10 times the one for Lame functions.
5. The developments Maple is bringing to the computer about PDEs & Boundary Conditions is yet one more example of the same: difficult knowledge becoming available to everybody, the same I could say about the DifferentialGeometry package, etc.
6. Last but not least, the whole CAS benefits enormously from the side-developments necessary to implement this more advanced material. As an example, take the developments that happened in the numerical evaluation of special functions in Maple 2017, only due to the requirements for the implementation of Appell functions. We don't advertise all of this, but it is there, and among the advertised things there is this new MathematicalFunctions:-Evalf package.

I frankly see all these as wonderful developments. They change not just the research but also the learning game, concretely and for good, merging the two things. It is difficult for me to understand how can you call - any of these - as "irrelevant distractions". It seems to me you have a different vision of what a CAS could be for.

Summarizing:

• We bring into Maple otherwise very complicated knowledge close to everybody, and in that way we play a bold role in both popularizing and helping develop otherwise difficult areas of knowledge.
• We bring, into the Maple CAS, knowledge that is popping up more and more in the current scientific literature (that is changing now faster than ever), and in this way we participate in the wave of expansion of knowledge that is happening today.
• The developments in Maple 2017 are not restricted to General Relativity - a relevant area of Physics - but also in Particle Physics, in Partial Differential Equations with Boundary Conditions, and in Special Functions, and not restricted to the new - exciting and increasingly relevant - Appell functions.

Next are things that you say which look inaccurate to me.

You say “there is much more than general relativity in physics”. But the Maple Physics package is not only nor mainly about general relativity: vector analysis and quantum mechanics are well developed fundamental parts of this package - see the links of my previous reply. There is also CAS-Maple-Physics-package thorough educational material developed, the mini-course for physicists. Physics actually covers most of what you study starting 1st year undergrad to what you see in a master in Physics course.

Then you say: “Meanwhile, whilst all the attention has been devoted to general relativity, other aspects of Physics and more general mathematical applications have been neglected.” The facts for me are that no aspects of Physics have been neglected. The Maple Physics project just advances each release some significant amount, here and there. From what I see as new in Maple 2017, there are also relevant developments in the special functions and differential equations areas.

You say “Even only a small fraction of physicists will ever use this [general relativity] functionality”. But then anyone googling for ‘ “General relativity” physics “2016” ’ (2.5 million hits), then for ‘ “Lame functions” mathematics “2016” ’ (750 hits), could conclude the opposite of what you are suggesting in your replies: the number of people interested in Lame functions is, frankly speaking, rather small if compared with the number interested in general relativity.

You say “what has happened to the long urged inclusion of all of Abramowitz and Stegun into Maple”. I hope you don’t take me wrong but it is my impression that, from the special functions documented by A & S in 1950, about what was relevant in 1950, basically, only the spheroidal wave and the Lame functions are missing in Maple. I do think that the spheroidal ones are worth implementing. Having said that, even regarding the Appell functions, appearing in the literature increasingly more during the last 5 to 10 years, I heard more people asking about than about spheroidal wave. Appell functions, as Heun functions, also have a tremendous generality, enlarging the mathematical language - and so our ability to express concepts - much more than the spheroidal wave or Lame functions.

You say “still other [functions] are incompletely installed, with poor or no transformations to included functions that run at better than a snail's pace”. From your replies as a whole, you seem to be referring to the Heun functions. These functions are neither incompletely installed nor do they have “poor or no transformations” included. The Heun functions just happen to be much more general than the rest of the functions of the mathematical language, so they can be expressed in terms of the other functions only in very-very few cases, and for those cases transformations are in fact provided in Maple. Try for instance FunctionAdvisor(specialize, HeunG) and you will see; change HeunG by HeunC or any of the other Heun ones and you will see more.

By the way, regarding this style of communication you use, with disqualifying connotation words  “… negligence, snail speed, poor, irrelevant, distraction, etc.”, I can see that other people, as it happened above in this thread, can find it harsh or even disrespectful. Generally speaking, I believe that to promote changes you can: a) try to make people feel ashamed in public about their work, thinking that this shame will make them do the developments you want, or b) try to excite people about their work, honestly showing how much advancement and potential is in their developments, and how some bits more here and there would complement their work beautifully.

And then, this is important, I feel that more than anything else: accept that, regardless of your communication style, people may differ from you. Think tolerance. Tolerance also for whatever you perceive as imperfection. This is one of the most important things. The other one that springs to my mind is to stick to the facts. Make your points only over the facts. I remember Russel saying these two things, that great British mathematician that was also a philosopher. Since then his words come to my mind repeatedly.

I hope these comments enrich the debate you are trying to make on these other topics, beyond my original intention of telling what I think are rather exciting novelties in the Physics package for Maple 2017.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

@J F Ogilvie 

The developments in the Physics package for Maple 2017 were not restricted to General Relativity and Particle Physics.

Also, as people using the package know, Physics has basic and advanced functionality for Quantum Mechanics too since it entered the Maple library, including a full implementation of anticommutative and noncommutative operators and functions, related operations (including functional differentiation), Commutators, Anticommutators, Creation and Annihilation operator commands, pre-defined and customizable algebra rules, a whole implementation of Dirac notation for vector calculus on a space of quantum physical states, … to mention but a few; the list of functionality available is really large.

By the way, we are able to advance General Relativity using Computer Algebra and Particle Physics in Maple 2017 only because we already have the basic functionality in place, and as it is the case of science in general, it is the simultaneous development of both - basic and advanced - that makes this package evolve so fantastically.

To stick to the facts, it is useful to point to some application examples on Quantum Mechanics posted in this Mapleprimes forum in the past, developed using the same Physics package that recently implemented this most thorough digital database for Exact Solutions to Einstein's equations in existence and now the ThreePlusOne package towards Numerical Relativity:

• Quantum Mechanics using Computer Algebra 
• Quantum Mechanics (II)
• Superfluidity in Quantum Mechanics
• Quantization of the Lorentz Force
• Quantum Mechanics: Schrödinger vs Heisenberg picture

The following link is also interesting because it shows a balanced set of applications in different physics areas, and the section on Quantum Mechanics also features a subsection on the use of the Physics package in developing proofs regarding properties of operations between quantum operators, something I don't recall having seen before in any computer algebra system, commercial or brewed at universities

• Computer Algebra for Theoretical Physics

For completeness, this other link to a mini-course on computer algebra for physicists hits the Education aspect and is somehow ambitious, in that it shows an entry point to using such a wide-range-of-areas package as Physics is, while at the same time it is a compact tutorial for people who - simply put - never used computer algebra

• Mini-Course: Computer Algebra for Physicists 

So, strictly sticking to the facts, I'd say that Maple's Physics is rather thorough regarding the areas in physics that it covers, and for which it provides both basic and advanced functionality, as opposed to what you say, that "in Maple Physics, all the attention has been devoted to general relativity" and "other aspects of physics have been neglected".

The rest of your reply is about Special Functions. There too I think that Maple is pretty strong, thorough and with wide - unique - functionality, from the FunctionAdvisor to the conversion network for mathematical functions, the package for Symbolic Sequences, or the level of development of Symbolic Differentiation, the list is large ... and also with very interesting new special functions and related developments in Maple 2017, but all this is not the topic of this post so I'll not comment here.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

@John Fredsted 

After fixing the "too stringent type checking on the input", the command works as it is expected (until further improvement): it displays an error message saying why it cannot perform the computation. That is why the message reads "unable to handle <this>", as in a programmed message from the program to the user. As said I am also rather busy nowadays, but improving the code to pass ahead of this interruption looks easy a priori ... I may dedicate some time to this next week.

As for the other error in simplify/do that you show, before using a command, or before posting about an error that results from using it, it is convenient to look at its help page, for instance to see whether you are using it correctly. Your use "PerformOnAnticommutativeSystem(PDEtools:-ConservedCurrents(pde));" is incorrect and not according to what the help page tells.

PS: I have no idea who moved your reply.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft