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

A workaround for installing the Maplesoft Physics Package in the Windows platform (some people experienced problems with that) or for the case other MapleCloud packages, is available. See "Workaround for the problem of installing MapleCloud packages in the Windows platform"

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

@JonMcLoone 

... hmm I wonder how is that my name ecterrab appears in your reply, Jon. In my reply to you in that Mapleprimes post of 2015, I gave my opinion that both systems have their strengths. Then elaborated about Maple's capabilities in mathematical functions (FunctionAdvisor), mentioned DifferentialAlgebra, DifferentialGeometry, Differential Equations and Physics, areas where I think Maple has better performance, or in the case of Physics, there is nothing really similar in Mathematica to compare with. I work on these projects and feel comfortable talking about them. But  I don't write Maple's advertisements - but for perhaps some sentences related to these areas just mentioned only - not the topics of this thread.

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

@rlopez 

Hi Robert,

That option exists, alias. Further below Pascal mentioned it in the context of Latex, but it is of course valid outside that context too. For example, something in your mapleini file like 

alias(seq(c[k]=_C||k,k=1..10));

would make 1) the _Cn invisible forever (you basically never use equations of order > 10, and if it where the case, make it 20) and 2) keep all the library working properly; many library routines scan for _Cn, they will all find it even when they look like c[n].

On the other hand, making an option like in LinearAlgebra:-LeastSquare has the obstacle that all the library routines that scan for _Cn will not find it anymore, because now something else would be in use (and no alias around to help to find the right object).

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

@nm 

In view of your goal being Latex related, Pascal's idea seems to me simplicity at its best. I like that. You can complement his suggestion to cover your concern about N as follows:

Besides, suppose you know the differential order of the equations you are handling, and you know they are all of order 5 or less. Well, then N = 5 suffices. In the _Cn, the maximum value of n is the differential order.

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

@Carl Love 

You are 100% right. Sometimes my brain does literal translations without thinking ... I fixed the pages now; not differential to non-differential in: PDEtools/ConsistencyTest, PDEtools/DeterminingPDE, PDEtools/Infinitesimals, PDEtools/InvariantSolutions, PDEtools/ReducedForm, PDEtools/SimilaritySolutions and PDEtools/SymmetryTest.

7x Thanks :)

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