## 2453 Reputation

14 years, 77 days

## several issues...

There are several issues to discuss in what you say, I address only a few. When you say "the answer is always true" you are talking true in mathematical sense. A computation of a "true" value is something different. In your worksheet you are testing equality in a boolean context, equivalent to using evalb, which tests memory address equality. This is a particularly weak representation for mathematical equality as it may miss many cases, precisely what you are showing. Maple has several tools testing equality at different strengths. In particular verify provides both ready to use and programable equality verifications much stronger than evalb.

## antecedents...

Jacques has told here several stories of individuals introducing a regression in the belief they were making an upgrade.

## not always works...

For every command, or combination, there are always clases of expressions for which it will fail. This is basically the zero equivalence problem, generically known to be unsolvable. But, in practice, it can be worked out for some clases of expressions.

## expand vs simplify...

Obviously, you need expand, rather than simplify:

> simplify(x*(1+x));
x (1 + x)
> expand(x*(1+x));
2
x  + x

But expand does not map automatically as simplify. See the output of:

trace(expand):
trace(simplify):
simplify(M1+M2);
expand(M1+M2);

The documentation of both commands is somewhat poor.

## Flip integration limits...

OK, so split works but you want additionally to flip the integration limits of the resulting integrals where u becomes the lower limit. I am adding this part to my answer.

## would not work?...

I wonder what do you mean exactly by would not work.

## so you know...

So you know already his opinions on these issues. I consider that the founder of Maple understands them much better than us...

## partially documented...

No, this syntax was introduced system-wide in Maple 12, see ?updates,Maple12,symbolics (actually it was introduced in Maple 11 within a restricted scope). But its documentation is poor, mainly a paragraph in ?value. And sadly, its implementation was never finished, meaning that some commands still do not handle properly this syntax after seven years or so.

I suggest you to read the interview to Gaston Gonnet linked above.

## an alternative solution...

Why is a story. Shortly, an alternative solution for your case is using a conditional rule like:

> applyrule(conditional(Int(f::anything, r::equation) = z,
_type(_lhs(r),identical(t))) , Int(f, t = 2 .. 5));
z

## More openness...

Yes openness was one of Maple great strengths, but it is far less than it was. As you have described in this thread merely inspecting the code of a package may involve a lot of difficulties for the user nowadays. It is not enough that you post fixes to Library code on this site. It is necessary that many more members of the user community get involved as it was in the far past. But it would need a different approach from Maplesoft, providing access to documented source code, a platform for collaborative development, and perhaps a different business model.

In this interview cited by Jacques, Gaston Gonnet made though the comment: "Maybe now it's even too late to go that route" (now was 2005).

## wait for a point-release fix......

Note that your narrative is approaching Wolfram's Why You Do Not Usually Need To Know About Internals.

## not so time consuming...

I have written time ago some tools that make all that cycling over members of modules, showing the overall structure, the code of procedures, content of tables, etc. Idem for old style "slash" hierarchies, like `xxx/yyy/zzz` (note, by the way, that some packages have a mixed module-slash organization). I use them regularly for looking at diverse sectors of the system (e.g. Explore), sadly mostly undocumented. I think that writing the core of those tools took me a few hours at most.

I have not made significant timing comparisons between these two builtin procedures, but clearly, the order of the computations is different. Somehow add calls the expansion of the list, while `+` receives it expanded:

> X:=[1, 3, 8, 9, 10] :