@umbli 

Download dynBH_(reviewed).mw

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

@Preben Alsholm 

Sigh ... I'm sorry for that Preben. Your emails didn't arrive to me and are not in my spam folder either. I'll ask IT at Maplesoft, what could have happened. I'll send you the mla library by email.

PS afterwards: IT responded, and indeed there was a problem with email that got fixed only now, so physics @ maplesoft.com should be working fine now. 

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

@Sradharam 

Check the help pages. In ?PDEtools, you will see a command PDEtools:-SimilaritySolutions, and another one called PDEtools:-InvariantSolutions - all related to the Lie symmetry method. Click the corresponding links to see how those commands work.

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

Hi @vv 

That is a different topic - the one of this thread was about simplification of a generic %inert construction.

About the topics you mention, originally there was Int or Diff, then Sum, Limit and Product. At some point (around the year 2000) I introduced inert everything. You realize it was not possible to capitalize everything as the notational convention for inert - what about BesselJ, for instance, the active form is already capitalized. So it was decided to go with %whatever. But by the year 2000, there were too many uses of the old forms, so it was decided to keep them. That explains why there are two forms for only a very few commands.

That said, it is also true that not all the library adapted to this change. In some places, e.g. the one you are mentioning; I'm not sure how relevant that example about %gcd is, but it is true.

In part, the real problem is that the introduction of inert everything is indeed a radical change in a computer algebra system. Some people prefer the paradigm of all or nothing. I don't debate that, but mine is move in steps. At every release, more library commands understand inert everything. Incidentally, in the context of this thread, simplification of %whatever, to mention but one example, in the Physics Updates v.832 I updated `combine/range` to recognize %sum, %int  %product.

Something similar happened after the introduction of assuming - at each release more mathematical functions handle assumptions on their parameters. 

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

The adjustment to the Maple 2020 simplification of inert %int, %sum, %diff, %limit and %product  is now finished. Among the several possibilities, basically, and related to the comments above, I preferred to

• Do no value.
• Use more of the old routines simplify/<Int, Sum, Diff, Limit, Product> 
• Although the computational flow for - say %int and Int - is actually different,  do as much as possible to get the same simplification.

I think the result is good, as usual available within the Maplesoft Physics Updates. (I recall that a fix for the problems in installing MapleCloud packages in Windows is available.) If someone feels there is more to be done please post the example as a reply here.

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

@Preben Alsholm 

By constant, I meant "of Maple type constant." Zero is a special case. So what about simplify(%diff(x, x) - 1)? For several years that returns 0. We can echo the input instead, return %diff(x, x) - 1, and I wouldn't be so uncomfortable with that. There is a choice to do. You know, any choice has its + and its -. 

Since the first reply, I think we are all on the same page about: simplify/inert should not desinertize Int, Limit, Sum, Product or Diff, but we see some situations where we could tell the simplified result (e.g. 0), and one can always say that telling that result is equivalent to desinertize the input.

The first case we seem to all agree is when the properties of the input integral tell the result. Either regardless of the integrand, or because the integrand is 0. What about the slightly more general case where the integrand is a constant that does not depend on the integration variable? Since ages, for Int, not %int, simplify does this:

> simplify(Int(a, x));

              a Int(1, x)

What about the case of simplify( Int(1, x) - x ) ? Recall that we are talking about the result returned by simplify, not by a call to the inert function itself.

Also, till today the simplification of Int and %int returns different results - you @Preben Alsholm called the attention to that. Fixing that will naturally imply a slight change in the way we work with Int or %int or both. There is nothing intrinsically wrong with that. 

It is great that several people presented opinions. I still feel that there is no clear prescription on the table. I will do one more tweak to this, taking into account what is already clear.

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

I uploaded a new version of the Updates with the changes mentioned in the comments above, but for making the simplification of %int and Int work exactly the same way. The change I am still in doubt is to return value'd when the result is a constant, e.g. 

simplify( %int(sqrt(x^2), x = 0..1) );
                                 1/2

It worked this way since years but not with Int, only with %int, so keeping this result would slightly change the simplification of Int. On the other hand, things like %int(x, x), that were returning x^2/2 now return unevaluated, the same way with Int, 

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

@acer 
I'm sorry if I misinterpreted you. No, I was not talking about constant factors going from out the integral to the integrand. For integrals there are two simplification routines: `simplify/int` and `simplify/Int`. I don't intend to change any of them. Related to this exchange of ideas, what I intend is slightly change the simplification of expressions containing inert integrals to use one or the other simplify routine depending on the example (details in the thread above), and with no difference between Int and %int.

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

@Carl Love 

They appear in white in my Google Chrome ... but I wrote using Safari's dark mode ... It must be that. So far I mentioned three examples:

Then

and

Currently, and for many years they all return as I am suggesting; the last two return 0. If you change %int by Int you also get 0, so nothing of this is really new. The new thing would be to make the simplification of %int and Int work the same way. And make both closer to what you see at this moment in simplify/Int, so do not use value, but for a few exceptional situations like perhaps the above.

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

@acer 

Any change implies different behaviour, And if there is code depending on the previous behaviour, that code needs to adapt. It's always that way, uncomfortable to some point, and things change nevertheless. It is otherwise impossible to progress. So that is for me not an argument against change.

On to the topic: I'm here doing something few people do these days: listening. So far three people said things. While each person thinks her opinion is the good one, each opinion is only one in a universe of opinions. At my end, I am in charge of the simplifier, and it is my opinion that it is good to listen to others' opinions, think, then decide.

Int and %int currently behave differently under simplify. That is incorrect and, of course, we can continue incorrectly, but generally speaking, I prefer to fix these things. In this moment, as noted by @Preben Alsholm, simplify(%int(x, x)) returns x^2/2, unlike simplify(Int(x, x)) that returns Int(x, x). Whether that is convenient for you because you use Int instead of %int doesn't change the matter. Int and %int are two-supposed-to-be-the-same thing, the inert form of int.

The proposed change under consideration goes more into a) making simplify@%int behave like simpify@Int, so do not value things, b) in some cases we may want some equivalences detected - I mentioned some examples above, asked for "Opinions?"; and c) for Functions, (not int, diff, sum, product or limit), for now we may want to keep the current behaviour, where things like %exp(0) become exp(0) when exp(0) is something simpler.

To the side, your comment about "do not remove usefulness" sounds to me a bit out of place. Not only for what implies for me (the guy who removes usefulness? I feel more like the guy who perhaps thinks differently than you) but also because it could be read as "you think that whoever thinks differently than you is indisputably wrong." @acer , that is not useful. Let's just collect some opinions without disqualifying anyone's.

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

@Ambrozy Zbój 

Consider this example:

I prefer 0. One could argue this is not about value but about having the inert and active form at the same time. OK that is one exception where we want the inert to become active.

Still how about this other one

Again I prefer 0 and, more generally, if the result is a constant, I prefer it.

Opinions?

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

@Preben Alsholm 

Interesting question. I wrote simplify/inert in 2008. Revising the notes, I was not thinking of "value" but this:

Well, in the example you posted, indeed, that is the same as combining with value. Perhaps this other example illustrates the original idea of 12 years ago better:

Looking at this result today, I think I want it but can see it is debatable. We can also go with "yes but not in all cases," for example, not in the case of integrals, where the distinction between %int and int has perhaps a more special meaning: in several scenarios, we just do not want integrals computed, at all. In fact, although in computer algebra integrals are implemented as functions, before computer algebra, I never thought of an integral as a "function" to the point that when coding dsolve added `type/Function` to make this distinction clear.

Regarding the difference you noticed between simplifying %int and Int, that caught my attention too, is due to historical reasons only. There is `simplify/Int` from before the existence of inert objects, and simplify calls that routine instead of the more modern `simplify/inert.` That is to be fixed, %int and Int should go both either through simplify/Int or simplify/inert, depending on how this conversation ends.

So, opinions?

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

@Carl Love 

For me the important thing is, generally speaking, "give me the chance to reproduce it, and I will do my best to fix it, otherwise it is an impossible task". So although I realize the frustration this or that can cause, providing a way to reproduce the problem you are experiencing is the only reasonable or useful-in-practice way to go, I think. To the side, however, related: to invoke shame for a bug in code by others, or feel shame for a bug in your code, is never the way to go. And concerning 2D display of input, something I use and enjoy, I am particularly interested in collecting bugs, issues or suggestions. At every release, I see those fixed more and more.

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

Hi,

I just saw this post from 2018 ... Within the Maplesoft Physics Updates there is a new command, Latex (uppercase L), that has this issue corrected 

This command also provides more functionality than the old lowercase latex, for example: inert functions, that in the worksheet appear displayed in grey, are tex-translated with color:

and alias are taken into account, which allows you, for instance, to use an indexed c[n] instead of the old convention _Cn for integraion constants entering solutions of differential equations:

More important, the new Maple Latex command translates everything. So if you see it on the screen, expect to see the same in the tex translation - no exceptions. The trick for that is that Latex is based on the modern Maple Typesetting package. So, as soon as new mathematical notation is implemented in the system, it is automatically available in LaTeX form.

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

@nm 

To the side, I see _C1(n) in the solution you posted. That was meant to be _F1(n), according to notational conventions in all the DE code, but I see I forgot adjusting that an year ago. It is adjusted now, in v.824 of the Maplesoft Physics Updates.

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