@nm 

I answered that in the original thread.

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

@arcade 

You say:

"I expected that the function particularsol gives me the particular solution, but there is the cosine term, which belongs to solution of the corresponding homogeneous ODE." 

The particular solution solves the inhomogeneous ODE, not the homogeneous part. The output of particularsol is correct. There is nothing in the definition of particular solution that says that it "cannot include terms that, isolated, may also solve the homogeneous ODE."

In the help page of this command it is explained what it does. For your example, the code that solves the problem is LinearOperators[dAlembertianSolver]) - you may want to take a look at the corresponding help page too. You can see what code solves the problem by entering > infolevel[dsolve] := 3.

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

@nm 
Thanks! And sorry; in the midst of other things, one file escaped the update; this is a new option - tests were created only afterwards. It is resolved within the Maplesoft Physics Updates v.843 and newer.

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

@nm 

Latex is a replica of Physics:-Latex, with its own variables. It is a full replica. So either you use Physics:- prefixing everything or do not use this prefix anywhere. For example, Physics:-Latex:-Forget will clear the caches of Physics:-Latex, not Latex. At the same time, Latex:-Forget clears the caches of Latex, not of Physics:-Latex. Likewise, Latex:-UseTypesettingCurrentSettings is taken into account by Latex, not Physics:-Latex. Etc.

And yes, I am interested in feedback if something of this user-level Latex replica is not working. This Latex project started as a Physics project, but the result is relevant beyond Physics; the idea is to replace the old latex command with this new Latex.

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

@nm 

All Latex subroutines work cached. So in a situation like the one you are suggesting, where you change the settings on the fly, you need to clear the caches.

I adjusted the previous reply / foo procedure to include that call to Physics:-Latex:-Forget. You get this:

Note also that, in foo, I added return (to avoid noise in addition to the Latex translation, and removed your call to print that only added some white space after the returned result.

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

@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