Download Matrix_operations_without_specifying_components.mw

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

For asymptotics, the FunctionAdvisor only returns what the asympt command returns.

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

@_Maxim_ 

On day one (198?) people impemented d/dx signum(f(x)) = signum(1, f(x)). Posterior attempts to change this collided with different positions regarding the backwards compatilibity problem of such a change.

This derivative can be related to a Dirac distribution. The derivative of a composite function is also not implemented in this differentiation rule of day 1, and what for me is perhaps less natural: diff(signum(1, x), x) = signum(1, x),

Since the Maple Physics environment (package) is newer, these things got adjusted such that after you enter "with(Physics)", the derivative of a signum(f(x)) (composite function) works as expected for a composite function, the second and further derivatives also work as expected (e.g. d/dx signum(1,x) = signum(2, x)), and you can convert between all the complex components (e.g. convert these signum functions or their derivatives to argument, absolute value, Im or Re; the step relating to Dirac is however pending). These differentiation and conversion rules get redefined if you Setup(wirtingerderivatives = true) mainly allowing you to take z and \bar{z} as independent variables as frequently done depending on the context.

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

Hi,

I am not sure how useful this would be, but I may well be missing so many things ..., and regardless of that, your post does call my attention and curiosity. I think it would be an interesting extension of our current capabilities for the complex components (that is how they are referred within the FunctionAdvisor). Incidentally, when you load the Physics package, one Setup option is to use Wirtinger derivatives, not the same thing, but related to the topic of differentiation of the complex components, with respect to z and/or \bar{z}.

By the way in Physics there is an overloading of diff extending its capabilities in sevarail aspects, It would not be difficult to include this extension you suggest; and there is also a directional derivative command within Physics:-Vectors, and also a Physics:-LieDerivative one, a related concept present in DifferentialGeometry too.

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

Hi

This problem is now fixed. There may be time to include the fix in the upcoming dot release (2017.3). Meantime, this fix is available to everyone within the library distributed in the  Maplesoft R&D Physics, Differential Equations and Mathematical Functions webpage, that includes also other adjustments and improvements in the Physics, Differential Equations and Mathematical functions Maple libraries.

For some people with more expertise on MeijerG or generalized hypergeometric functions who are curious on what the problem was (besides the description I gave in the previous reply) please email me at physics@maplesoft.com.

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

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