that 'analytic' should be added, and that LinearMap and PolynomialMap are improperly placed (and used) in the lattice.

Knowing how LinearMap is used internally in assume, I think that 2 different concepts got conflated, and need to be teased apart again.

First, note that Maple's iscont routine is the traditional way to check continuity.  Its definition is the more usual one.

The continuity property seems to be both generalized (ie applies to functionals as well as to functions) and somewhat neutered (the bug with respect to constants that you found).  I am fairly sure that, using the right topology on the right space, Diff and Int are continuous (essentially because indeed they are linear maps!).  I wonder however if that is actually useful.

That was a mistake on my part, I meant dismantle all along, but I mistakenly typed disassemble.

By printing artifact here I mean that 2 different things print the same way.

I used disassemble in this case to look at the actual code for RealDomain:-limit, but I could have used ToInert as well.  But of these are extremely precise as to the exact details.

Interestingly, if one goes to a*y^2+b*y+c instead, then the system of equations easily implies that a(t)=0, so that if Runge-Kutta will be exact on some non-linear ODEs, one must look elsewhere than that simple generalization.

Strangely, the system one obtains from that modification is deemed inconsistent by dsolve (via casesplit?).  But that seems wrong - a bug?

I know for sure that they are made aware of certain posts, by employees who do read the forums. 

I know for sure that they are made aware of certain posts, by employees who do read the forums. 

This would be a bug only if r2c_handler were defined globally when the RealDomain:-limit function was loaded into Maple's library.  Binding is done statically, not dynamically (not to be confused with evaluation, which is fully dynamic). 

In this case, it is perfectly safe because r2c_handler is actually a lexical-local (i.e. it is defined in the RealDomain module), so that in fact both are equivalent.  Same goes for the clean routine.

What you are seeing is an artifact of Maple's pretty-printer, which does not make a distinction between names that are bound in different ways.

At least the 'community' is working on this.  In particular, see the paper by Behzad Akbarpour and Lawrence C. Paulson, MetiTarski: An Automatic Prover for the Elementary Functions recently presented at Calculemus 2008.  The work uses Isabelle and QEBCAD-B.  It proves significantly harder inequalities than those.

At least the 'community' is working on this.  In particular, see the paper by Behzad Akbarpour and Lawrence C. Paulson, MetiTarski: An Automatic Prover for the Elementary Functions recently presented at Calculemus 2008.  The work uses Isabelle and QEBCAD-B.  It proves significantly harder inequalities than those.

That this does not work for a Matrix seems to be an oversight in 'evalapply', the kernel routine which figures out what to do with ``weird'' applications.

But then again, there might be a good reason for it - how would evalapply work on a Matrix with no storage and funky indexing functions?  The only choice would be to copy it, which would ruin efficiency.

That this does not work for a Matrix seems to be an oversight in 'evalapply', the kernel routine which figures out what to do with ``weird'' applications.

But then again, there might be a good reason for it - how would evalapply work on a Matrix with no storage and funky indexing functions?  The only choice would be to copy it, which would ruin efficiency.

There were excellent reasons for the original Maple designers to use DAGs in the kernel, and for the original writers of the pretty-printer to follow suit.  It was presumptuous of the writers of the new pretty-printer to think that they knew better and could turn off this feature without paying the cost.  This example is a perfect example of this.

There were excellent reasons for the original Maple designers to use DAGs in the kernel, and for the original writers of the pretty-printer to follow suit.  It was presumptuous of the writers of the new pretty-printer to think that they knew better and could turn off this feature without paying the cost.  This example is a perfect example of this.

Honestly, I am unsure.  There are pros and cons, and I can't really see a winning argument for either side.  My current feeling is that:

1. The default evaluation environment should have a much strong zero-tester and normalizer
2. It should be possible to use other evaluation environments (at least locally) with different zero-test and normalizer.  Including turning off 'simpl' altogether.

Note that I don't mean Normalizer and Testzero -- mostly because these are not used pervasively enough!  Changing these has much less effect than desired.  One (partial) implementation strategy would be to have many more calls to Normalizer and Testzero in Maple's library and kernel.  But I am really not sure if that is actually the best way to go!