This initiative seems to me close and parallel to the Computer Algebra Test Suite described here. That is, as this field is so vast, it would seem wise that the different initiatives were coordinated.

Also here.

But here I am talking about statistics on large number of cases. If a numerical check were shown to be effective frequently I believe that it could be a useful addition (as everything employed with proper care!)

But adding an option to int, at choice of the user, for numerical checking the integral, could perhaps be helpful for a set of integrals at identifying "issues". I wonder whether this conjecture has been explored.

While theory and implementation on definite integration progresses, I think that the best practice is not to believe blindly on the results and recheck them in as many ways as possible and practical. Some options are:

1. Use the available symmetries. In this case it should hold

2. Watch the plot of the indefinite integral within the interval of integration for "something strange". In this case the finite discontinuity at the origin.

3. Evaluate the integral with another CAS as different programs/versions seem to use different "recipes". Eg. as pair of additional examples, in Mupad 4:

int(cos(t)*sqrt(cos(2*t)),t);

1/4*2^(1/2)*arcsin(2^(1/2)*sin(t)) + 1/2*2^(1/2)*sin(t)*(cos(t)^2 - 1/2)^(1/2)

While in Mupad 2:

int(cos(t)*sqrt(cos(2*t)),t);

1/2*sin(t)*(1 - 2*sin(t)^2)^(1/2) - 1/4*I*2^(1/2)*ln(I*sin(t)*2^(1/2) + (1 - 2*sin(t)^2)^(1/2))

Thank you for refreshing me about these options.

The subject of this thread seems to me quite close to this one for Axiom. Apparently, similar problems occur there. I wonder whether there is a comparative review about how CAS implement types, properties, etc.

Perhaps a wiki could help, among other things, to organize the access to this information.

Sadly, this is the fact. ?type states:

Note: The type function does not check assumptions, it only considers the object itself. If you are using the assume facility, it is recommended that you use the is function.

I think because the assume facility was added at a later stage in the development of the system, and was not fully integrated.

If Classic is frozen (and I am afraid that it will not be distributed, starting from some future version), I wonder whether an open source native GUI project makes (technically) sense with core Maple being closed code. Eg., could it work that Maplesoft opensource the Classic GUI if it were no longer interested in distributing it?

Classic does not 'get in the way' of doing work with the underlying Maple, while Standard still has glitches (even in worksheet mode) that can make it bothersome to use for someone who is not a beginner.

For this reason I would like very much to use Classic for daily work, but this work frequently involves plots, which, because of the problem reported here, and earlier elsewhere, look bad in 2D and horrible in 3D. (Note: I have not found yet any other application showing this same problem, ie it seems Maple specific). And the speed of plotting in M11 Standard (worksheet) has improved wrt M10 Standard. So, while in Windows, most of the times I choose Standard GUI despite of its very slow start and its glitches. It seems that the development of the Classic GUI is frozen (or close to). I wonder which is its future.

will find sums for mildly divergent series (documented on Wikipedia).

I think that it means what is called "antilimit" in that article. There is no article explaining this term in Wikipedia, and I guess that it applies to the value 1/(1-q) for the example of the Aitken method in the case abs(q)>1. Ie it seems to be defined by an analytic continuation. Can be proved that this procedure is unique?

I think that Maple is delayed on this issue. Several other CAS have already open bug tracking systems, eg: Mupad, Maxima and Axiom.

it is my personal experience that a lot of Maple users ``sit'' on their cache of (Maple) bugs that they encounter, rarely reporting them officially. Whenever they encounter someone somewhat linked to Maplesoft (like me), they spill their guts.

I shared this same experience while being ambassador of Maplesoft. So, I think that an open bug tracking system would help to canalize part of the bugs found by the user community. But I am doubtful about how many users would approach to a tracker, as reporting requires some effort, in particular when the site is run in a foreign language. And I would not paralyze such an initiative for fear of any individual.

This design pattern seems to work. Other design patterns have been abject failures [internal state, as in the assume system and unfortunately a few new packages; long weird names with lots of

I have wondered for years about the design of the assume facility and whether it could not work better if implemented using attributes. If this impression were right, is there a chance of such a reimplementation?

First, rest assured that we don't really expect users to figure out how to use the internal typesetting representation and generate those ugly strings with msubs and all. You shouldn't have to do this.

Certainly, there should be a command/package to convert from TeX into this internal typesetting representation.